I seem to have a problem with timeouts and forms authentication loops in my application. The application is MVC3 based and is AJAX heavy. I find that even when a user is continuously working on the application and not being idle, sometimes they get kicked out and then forms authentication goes into a redirect loop with a 302 error.
The application is hosted with a provider who tells me they have increased the session timeouts to 60 mint. My web.config setting for the application is as follows.
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880" cookieless="UseCookies" slidingExpiration="true"/>
</authentication>
Why would I be getting the session timeouts? Is there any setting I can check up/change to stop this happening?
Thank YOu,
I finally figured out what was happening. Firstly, I had a Session filter on my base controller, that was catching session timeouts and redirecting it to Account/LogOn. Removing this took out the redirect loops.
I also changed my code to NOT use Session variables, to get around the issue of frequent session timeouts. And this has now been resolved. I hope this helps anybody else out there struggling with similar issues. Do remember and check for any kind of custom attribute filters you may be using in your code.
Related
Can somebody please let me know what are the reasons for your authentication to die suddenly, even when you are working on an application without any idle time? Both with and without AJAX calls. And what are the different reasons for getting a 302 redirect from an MVC3 application to the Logon page.
Been struggling with an issue with timeouts that happen at random. Sometimes within a few minutes of login to the application and sometimes you can go for hours (with/without idle time) without being thrown out.
Thank You
Please see the answer on this question. This has resolve my issue with redirect loops.
IIS Session timeout and Forms Authentication loop
I have a jQuery Mobile page that works ok in Safari on iPhone (iOS 5+). And when clicking at this link...
#Html.ActionLink("Click to download", "Download", "Home")
...I am taken to myapp.com/Home/Download
When clicking the same link in Chrome on iPhone I'm taken to myapp.com/(F(LzXF8gDEEPPgR7F_UZ0wf2uWg1e-aK1mgwtvzxCTIgflM43gYVEY06XIIq91OLlyjnRXo78AXHQLoXMUXRjOLKQltEhrsYgmTnSNsHzBfl01))
/Home/Download
Does anyone have any idea why the URL gets so messed up? (From that url no subsequent link works..)
Your user agent (browser) doesn't support cookies or has cookies disabled. In this case ASP.NET falls to a compatibility mode in which it tracks user Sessions by appending the session id in the url. So now all your urls will have this id. It's perfectly normal behavior.
The same will happen not only with ASP.NET Session but with Forms Authentication cookies. You could disable this behavior for ASP.NET Session in web.config by forcing to always use cookies:
<sessionState cookieless="UseCookies" />
Obviously if the user disables cookies, your application will simply crash as it won't be able to track users. And absolutely the same goes for the forms authentication cookies:
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880" cookieless="UseCookies" />
</authentication>
I had the same problem and,
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880" cookieless="UseCookies" />
</authentication>
solved my problem..
I thing you have to force browser for using cookies because when I checked my settings on my ipad, chrome was already allowing them.
Thanks again..
I realize this is an older post, but..
I believe this is a bug with the newest release of chrome iOS v 30.0.1599
As Daren stated this is the .net framework using the URL to hold the authentication data that otherwise would be in the auth cookie. This is called cookieeless session.
.net should not be interpreting the user agent as one that does not support cookies.
I added testing Request.Browser.Cookies to my login page and am seeing this version of chrome showing as false. This is certainly a bug in the chrome release. This seems to only happen after some post backs and will not resolve itself even with clearing the cookies and data and cashe the content settings.
The only way to solve is uninstalling chrome and using Safari. I am using ios7.
I would live to know how to resolve this but currently we are advising our clients who use iOS chrome to not update or use Safari and uninstall....
Mark
I have a MVC3 project for running on the iPad in the web-app mode. I use FormsAuthentication to realize a login/logout functionality which calls FormsAuthentication.SetAuthCookie(model.Username, true) to store the login information into a cookie. In all major browser including the safari mobile the cookie is saved persistend, across sessions. Only in the web-app mode the cookie is sometimes cleared during browsing the web-app and it is definitely deleted after closing the web-app. Is there any possibility to save the login information across session in web-app mode, too?
I know that the HTML5 local storage feature could be used, but I've no idea how to implement FormsAuthentication.SetAuthCookie(model.Username, true) manually by using the new local storage. And besides that, I'm not sure whether the local storage is safe enough to store such critical data.
I found the answer after a lot of research: You have to force the usage of cookies in the authentication node of web.config through cookieless="UseCookies":
<authentication mode="Forms">
<forms cookieless="UseCookies" loginUrl="~/Account/LogOn" timeout="2880" />
</authentication>
I have the following in my web.config
<sessionState mode="InProc"
timeout="2"
cookieless="UseCookies"/>
<authentication mode="Forms">
<forms
loginUrl="~/Account/LogOn"
timeout="1"
cookieless="UseCookies" />
</authentication>
As far as I understand in MVC3 (or in Asp.Net) sessionState controls when the user's session on the server times out
and the forms authentication timeout controls when the user will be forced to log in to the website again.
This doesn't seem to be exactly true: If I remove the sessionState section from my web.config the timeout in the authentication section is
completely ignored - it seems to just timeout after some default length of time.
In fact the session state timeout seems to be required to control when authentication times out. This doesn't make any sense at all.
Can anyone tell me what I am missing here?
This is related to this question that I asked, but I didn't get to the bottom of why this is the case.
Session timeout is independent of forms authentication timeout.
You didn't elaborate on how you created your ticket, so here are the most common quirks which may affect your observations:
If you instantiated the auth ticket yourself, then the timeout setting in
the config file has no effect.
Sliding timeout is a little funky, the ticket will not be extended unless you visit again in the last-half of the window.
You might want to check out this article for an overview:
http://support.microsoft.com/kb/910443
I've got a site that's integrated with WIF for security and mostly everything is ok. It's redirecting and dealing with load balancers etc.
I've noticed on a few requests it's bouncing to the sts and back, if it's a get request not a problem but it's happened a few times with AJAX requests and also with regular post requests.
I'm thinking that other people must have the same issue's and that I must of missed something in the configuration. I really don't fancy writing a custom implementation to deal with this requirement.
Any help?
Thanks
It will only redirect if the resource (page, image, CSS, etc.) is secured and needs the user to authenticate. If you need to make sure that this doesn't happen for certain areas, you can try allowing anonymous access within the web.config:
<location path="UnsecuredResource">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
What's happening with the hop is that the client-side authentication has either expired or does not exist so the browser is redirected to the STS. The STS has a persistent cookie that recognizes the user from their previous login so it simply authenticates and sends the user back to the application, which signs them in automatically.
If the session is expiring on the client side, that could be causing the need to re-authenticate. Make sure there isn't anything that would be causing the session to expire or get lost.
Hopefully this helps. A little more info would help to debug this issue.