RE: forms authentication cookie problem

From: Mike Moore [MSFT] (michmo@online.microsoft.com)
Date: 04/02/03 

From: michmo@online.microsoft.com (Mike Moore [MSFT])
Date: Tue, 01 Apr 2003 23:46:47 GMT

Hi Neil,

I found a few articles which might explain your problem. If any of these
help, it will probably be the first one.

324488 Forms Authentication and View State Fail Intermittently Under Heavy
Load
http://support.microsoft.com/?id=324488

810836 Membership Forms Authentication Does Not Redirect Properly When
http://support.microsoft.com/?id=810836

279186 Internet Explorer Drops Site Server Cookie for Intranet Site IP
Address
http://support.microsoft.com/?id=279186 

---
Another possibility (though NOT likely) is the cookie path. By default, 
forms authentication sets the path for its authentication cookie to "/". If 
you change the settings to specify a specific path, then the following 
might be the problem.
If you set the path for a cookie to a specific path, then all users who 
browse your page MUST use the same upper & lower case characters to view 
your page as you set in the path. If they use different upper/lower case 
characters, the browser will still request the page, but the browser will 
not send the cookie along with the request.
What does this mean?
Suppose you have a web application named "Sales" and you set the web.config 
to give the forms authentication cookie a path of "Sales". Then someone 
browses your page:   http://localhost/Sales/MyPage.aspx. It works fine. 
Next, the same user browses http://localhost/sales/MyPage2.aspx. It fails. 
They get redirected to the login page.
Why? Because the browser did not send the cookie. The browser saw that the 
path you requested "/sales" did not match the cookie path "/Sales". So, the 
browser did not send the cookie and the server thought you were not 
authenticated. If the user tried again, but happened to type "Sales" on 
this next attempt, then it would work.
Again, this problem with upper/lower case sensitivity is only a problem if 
you specify a path for the authentication cookie. The default is "/" which 
does not cause this problem.
---
I hope the above helps.
If you need further assistance, then the next step is to log the network 
traffic while one of these errors is occurring. NT4 Server and Windows 2000 
Server (and advanced server) include a utility named NetMon which can be 
used for this. It's installed via Add/Remove Programs in the Windows 
Components section.
Also, to proceed with digging into NetMon logs is beyond what we can do 
within the newsgroups. In case you need it, here is some contact 
information for Microsoft support.
* Microsoft support home page: http://support.microsoft.com.
* To view support options: 
http://support.microsoft.com/default.aspx?scid=sz;en-us;top.
* To submit an online request: 
http://support.microsoft.com/default.aspx?scid=fh;en-us;incidentsubmit.
Thank you, Mike Moore
Microsoft, ASP.NET
This posting is provided "AS IS", with no warranties, and confers no rights.
--------------------
| >Content-Class: urn:content-classes:message
| >From: "Neil Mc" <neil.mcilroy@centaurnet.co.uk>
| >Sender: "Neil Mc" <neil.mcilroy@centaurnet.co.uk>
| >Subject: forms authentication cookie problem
| >Date: Tue, 1 Apr 2003 08:36:02 -0800
| >Lines: 18
| >Message-ID: <046301c2f86c$c8863430$2f01280a@phx.gbl>
| >MIME-Version: 1.0
| >Content-Type: text/plain;
| >	charset="iso-8859-1"
| >Content-Transfer-Encoding: 7bit
| >X-Newsreader: Microsoft CDO for Windows 2000
| >Thread-Index: AcL4bMiGxq9bcjKkTO655mif4Kdx7A==
| >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
| >Newsgroups: microsoft.public.dotnet.framework.aspnet.security
| >Path: cpmsftngxa08.phx.gbl
| >Xref: cpmsftngxa08.phx.gbl 
microsoft.public.dotnet.framework.aspnet.security:4654
| >NNTP-Posting-Host: TK2MSFTNGXA01 10.40.1.47
| >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
| >
| >We currently have a problem with forms authentication on 
| >a web site whereby users are intermittently getting 
| >redirected to the login page even though they have a 
| >valid persistent cookie setup.
| >
| >If the user goes back and tries to load the page again 
| >they can normally get through as expected.
| >
| >It is as though the cookie is "lost" or not detected on 
| >occasion by forms authentication.
| >
| >The problem has been replicated with a number of 
| >different browsers.
| >
| >Has anyone else experienced similar behavior or have any 
| >suggestions as to the cause?
| >
| >
| >

Relevant Pages

  • RE: Authentication from another Application on server
    ... I have two web applications which both use forms authentication. ... server and also where they're on different servers. ... Both of these describe aspects of arranging for the same cookie to be used ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: REPOST - IIS6 /WebDAV/NTLM/Kerberos and Remote Storage
    ... >are using to authentication. ... Kerberos tickets target a service ... >authenticate to IIS from the client browser. ... structure on a Win2K server. ...
    (microsoft.public.inetserver.iis)
  • Re: client gets always every first time for every page a 401
    ... When the browser makes a request, ... > the first request to be Anonymous. ... If the server does not accept Anonymous or if the Anonymous ... >> Basic or NTLM authentication, it does not fall back to Anonymous during ...
    (microsoft.public.inetserver.iis.security)
  • Re: IIS Log Files logs 401 HTTP Codes
    ... the browser makes requests assuming no authentication is ... Suppose the browser makes an anonymous request to a server that REQUIRES ...
    (microsoft.public.inetserver.iis.security)
  • RE: logout a browser under integrated security
    ... You may be able to force something through code, but not server ... same browser session, even though they'll initially see a login prompt ... re-authenticate when they have the same browser session open on the client. ... the article Security and Authentication in Content Management Server you ...
    (microsoft.public.inetserver.iis.security)