So recently we had a couple of our sites randomly having weird issues of injecting strange characters in the URL when a user browsed the site in IE10. At first glance I thought the values were GUIDs but after some great help form
Juraj Ondrus (Head of
Kentico Support) I discovered the values were in fact the session id. After a quick search I found that there is a known issue with .NET 4.0 and the IE10 User-Agent causing ASP.NET to not use your
Set-Cookie settings for your application.
What it looks like
1. User attempts to log into the site using IE10
User browses to login page
2. User is re-directed back to the log in page, and logs in again. After logging in, the URL contains the session values.
IE10 adds session to URL
3. Using Fiddler, you can view the response from the server with the session values and the dreaded
Object Moved to Here
Fiddler shows response information
Some notes about the behavior
- The issue only seems to occur in IE10. Previous versions of IE and most other modern browsers don’t’ seem to be affected.
- If the site is using Forms Authentication, you may get redirected back to the login (as above) due to the session not being found and the site redirecting you to log in again.
- The issue seems to be isolated to .NET 4.0
How to fix it
Fixing the issue is relatively simple. There is a small web.config change you can add which should do the trick. If not, Microsoft has a hotfix that addresses the IIS side of things, which also should resolve it.
web.config
The web.config change is to explicitly set the "cookieless" setting in the
Forms Authentication section. This forces the server to always use cookies.
<authentication mode="Forms">
<forms loginUrl="CMSPages/logon.aspx" cookieless="UseCookies" defaultUrl="Default.aspx" name=".ASPXFORMSAUTH" timeout="60000" slidingExpiration="true" />
</authentication>
Hotfix
The hotfix updates the definitions in the browser definition file on the server. This helps IIS identify the browser the user is using and properly set the cookie settings.
http://support.microsoft.com/kb/2600088
NOTE
The
Fiddler response shows the
Object Moved To Here behavior, which anyone with some years of .NET development is unfortunately familiar with. It’s pretty ambiguous and very hard to track down. This behavior is often caused by a redirect or interaction with Session and the server cannot match up the user with a valid session for some reason.
Hope this helps you avoid some issues in the future!
Tip
If you’re not using Fiddler you should be! You can get it
here and see everything you wanted to see in your traffic!