Article ID: 910439 - View products that this article applies to.
ASP .NET Support Voice Column
Troubleshooting Forms AuthenticationTo customize this column to your needs, we want to invite you to submit your ideas about topics that interest you and issues that you want to see addressed in future Knowledge Base articles and Support Voice columns. You can submit your ideas and feedback using the Ask For It
(http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=)form. There's also a link to the form at the bottom of this column.
Welcome to the ASP.NET Support Voice column! My name is Jerry Orman. I have been with Microsoft over 5 years, and have spent most of my time focused on Web-related technologies such as Microsoft FrontPage and the new Microsoft SharePoint technologies. I have spent the last year working with Microsoft ASP.NET as a support engineer. This month in the Support Voice column, I am going to explain how to troubleshoot Forms Authentication in Microsoft ASP.NET.
When you use Forms Authentication in an ASP.NET application, you may find it necessary to troubleshoot a problem that occurs when the user is randomly redirected to the login page. In an ideal world, this problem would occur in a manner that would let you easily attach a debugger and capture the problem. In production environments, however, this is rarely the case. To troubleshoot a random problem like this one, you need to log information related to the problem so that you can narrow down the root cause.
In this column, we'll briefly cover the Forms Authentication concept. We'll then look into which scenarios lead to a user being redirected to the login page and how to capture data that is relevant to isolating the problem. We'll also cover how to implement an IHttpModule interface to log the Forms Authentication information.
Forms Authentication OverviewWhen a user authenticates to a Web site by using Forms Authentication, the server creates a cookie. The value of the cookie is an encrypted forms authentication ticket. The cookie is passed to the server on each request to the application, and the FormsAuthenticationModule class decrypts the cookie value and determines if the user is valid or not.
By default, the FormsAuthenticationModule class is added in the Machine.config file. The FormsAuthenticationModule class manages the FormsAuthentication process.
The following is an entry from the Machine.config file:
The general HTTP traffic for authenticating by using Forms Authentication looks similar to the following:
http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(vs.71).aspxFor more information about sharing forms authentication cookies, visit the following ASP.NET Web site:
Reasons that a user may be redirected to the login page
The forms authentication cookie is lost
In this scenario, a user logs on to the Web site. At some point, the client sends a request to the server, and the FormsAuthenticationModule class does not receive the cookie. You can determine if a user request does not contain the cookie by enabling cookie logging in Microsoft Internet Information Services (IIS). To do so, follow these steps:
Note You can use Log Parser to parse the IIS Logs. To download Log Parser, visit the following Microsoft Web site:
http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07After you have the list of requests from that specific user, search for the requests to the login page. You know they were redirected to this page, and you want to see the requests before the redirection occurred. If you see something similar to the following, the client either did not send the cookie or the cookie was removed on the network between the client and server.
This is the initial login.
These are other requests, followed by a request to a page on the site without the .ASPXAUTH cookie.
Collapse this tableExpand this table
Collapse this tableExpand this table
Note The first request from that user is not likely to have a forms authentication cookie unless you are creating a persistent cookie. The IIS Log will only show you the cookies that were received in the request. The first request to have the forms authentication cookie will be on the request after a successful login attempt.
The forms authentication cookie can also be lost when the client's cookie limit is exceeded. In Microsoft Internet Explorer, there is a limit of 20 cookies. After the 20th cookie is created on the client, previous cookies are removed from the client's collection. If the .ASPXAUTH cookie is removed, the user will be redirected to the login page when the next request is processed.
You can troubleshoot these two scenarios in the same way. Look at the request just before the redirection to the login page. If the request to this page generates cookies, this will be something to investigate.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/306070/ )Number and size limits of a cookie in Internet Explorer
You can use Fiddler to view the HTTP headers that are sent to the client. After you capture the traffic, double-click a request, and then click Headers to see the Set-Cookie header. If you trace a successful login, you will see the Set-Cookie header in the response of a successful login.
To download Fiddler, visit the following Fiddler Web site:
After the request leaves the client, there are various layers that can affect the packets that are being sent. To determine if a network device is removing the cookie, you have to capture a network trace on the client and the server, and then look in the body of the request for the cookie. You want to look at the client request to make sure that the cookie was sent, and check the server trace to make sure that the server received the cookie.
This is a GET request after the user has been authenticated. The forms authentication ticket information is highlighted in blue. This confirms that the cookie information left the client. When you use a network capture tool, like Netmon, you see the traffic that actually went through the adapter.
When you look at the request that reached the server, you want make sure that the server received the same information that the client sent. If the server did not receive the same information, you need to investigate other devices on the network to determine where the cookie was removed.
Note There have also been instances of ISAPI filters removing cookies. If you confirm that the Web server received the cookie, but the cookie is not listed in the IIS logs, check the ISAPI filters. You may have to remove the filters to see if the problem is resolved.
The forms authentication ticket times outThe other common cause for a user to be redirected is if the forms authentication ticket has expired. The forms authentication ticket can time out in two ways. The first scenario occurs if you use absolute expiration. With absolute expiration, the authentication ticket expires when the expiration time expires. For example, you set an expiration of 20 minutes, and a user visits the site at 2:00 PM. The user will be redirected to the login page if the user visits the site after 2:20 PM.
If you use sliding expiration, the scenario is a bit more complicated. The cookie and the resulting ticket are updated if the user visits the site after the expiration time is half-expired. For example, you set an expiration of 20 minutes by using sliding expiration. A user visits the site at 2:00 PM, and the user receives a cookie that is set to expire at 2:20 PM. The expiration is only updated if the user visits the site after 2:10 PM. If the user visits the site at 2:09 PM, the ticket is not updated because half of the expiration time has not passed. If the user then waits 12 minutes, visiting the site at 2:21 PM, the ticket will be expired. The user is redirected to the login page.
One way to approach this type of issue is to log the forms authentication cookie and ticket information. This way, you can see if the cookie was received by IIS and what the values are. You can do this by writing an HttpModule, and then plugging that module into the request pipeline. You will not have to modify your application's code to get the information you need.
The attached sample works in the Microsoft .NET Framework 1.1 and the .NET Framework 2.0 and has comments throughout. The sample includes the following files:
I'll point out the main areas here:
As always, feel free to submit ideas on topics you want addressed in future columns or in the Knowledge Base using the Ask For It