On the same domain - it's not too big, the entire structure looks like this:
<website root folder> website starts here in IIS
----[web.config] (let anyone in, no auth req'd)
----[content]
----<securesite subfolder> new app in IIS + req's SSL
--------[web.config] (use forms auth, path="/")
--------[login.aspx]
--------[index.aspx] ("welcome" page, public side requests to enter
securesite)
--------<securesite area 1 subfolder>
------------[web.config] (allowed/denied roles)
------------[content]
--------<securesite area 2 subfolder>
------------[web.config] (allowed/denied roles)
------------[content]
--------<about 12 more areas, structured alike>
So from the public http/80 side, user requests securesite/index.html on the
https/443 side in the "securesite" app root; the forms auth in the
securesite app sees the user is not logged in yet and gives them login.aspx.
User enters creds, login.aspx page makes an .ASPXAUTH cookie on their client
and redirects to index.aspx - global.asax impersonates, index.aspx is
delivered, trace shows .ASPXAUTH exists, all appears well.
Next request to (pick any) "<securesite area X subfolder>" sends you back to
login.aspx - .ASPXAUTH cookie is *not* listed in the trace data, only
ASP.NET_SessionID remains in the cookies. The SessionID stays consistant as
you play with this so I think it's retaining the session data OK. But for
some reason the browser is throwing out .ASPXAUTH? I've got my browser
security completely bottomed out for the purposes of testing this and it
doesn't seem to matter. Using the same code that worked a few weeks ago -
can this be a server config issue? Web.config problem? Timeouts on session
& forms auth in web.config are set to 30 mins.
"Raterus" <ra*****@spam.org> wrote in message
news:u3**************@TK2MSFTNGP12.phx.gbl...
are these pages all on the same domain name (as far as the browser knows)?
also, have you set the path of the Forms Authentication cookie so that all
the pages can read it. "/" works best
--Michael
"23s" <as**@asdf.com> wrote in message
news:qZ********************@speakeasy.net...
I had this problem in the past, after a server reformat it went away, and
now after another server reformat it's back again - no clue what's doing
it. Here's the flow:
Website root is public, no SSL no forms auth. One of the subfolders in
the public area is the root of a "protected" area; SSL is required from this
subfolder on forward and a web.config in the subfolder specifies forms
authentication. From the public area, I provide a link to a "welcome"
page in the protected area - if welcome page is requested, user is bounced to
login.aspx, and if successful login (integrated with AD) they get the
welcome page.
This part works, I can arrive to the site, request the protected "welcome"
page, get the login.aspx, log in with my AD creds, and get the welcome
page. Turning trace on shows the forms auth cookie to exist on the welcome page.
Because I am integrated with AD I'm using role-based security in
web.configs and so I'm impersonating in every subsequent request. On the next
request, the forms auth cookie is gone when Authenticate_Request fires. AFAIK I
don't have any code between the output of the trace on "welcome" page and
the Authenticate_Request in global.asax. The cookie is being destroyed
sometime after I login and the welcome page is delivered, but I can't
figure out where or by what.
Consequently, the only part of my secure area I can access is the welcome
page. Once I'm there, my cookie goes bye-bye and any requests in the
protected area simply bounce me to the login screen again.
What would cause a cookie be created and then seemingly disappear once I'm
logged in? The website code is stored in VSS and hasn't changed in
months; this code was working last week before I reformatted the web server, so
I'm suspecting a server configuration issue - the web.configs may have
changed, although I cannot seem to find anything wrong with them.
