I believe I have studied all related stackoverflow questions as well as other web resources, but am still having this problem a dozen times or more daily in a 24x7 web app that is used by about 20 users at a time.
Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket supplied has expired.
Users are saying that they are getting logged out earlier than the 60 minute timeout. (Some of the forms in the app take a long time to fill out. Users are interviewing people and writing notes, which can take a long time. So it's frustrating if you save the form after 20-30 minutes of slowly entering notes and it logs you out when you submit the form.)
Some details:
This is a single web server running IIS 7.5, not a form (the
database is on another box). All servers are VMs
IIS session state
is set to "In Process", and under cookie settings the timeout is 60
minutes.
The App Pool has idle timeout set to 60 minutes and
recycling interval to 29 hours
I don't see any errors in the event log prior to these "ticket expired" messages that indicate a worker
process failed or the app pool was recycled.
And finally a snippet from the web.config:
<authentication mode="Forms">
<forms loginUrl="~/Account/Login.aspx" timeout="60" protection="All" slidingExpiration="true" />
</authentication>
Any help to track down these session timeouts would be appreciated.
I have used jquery idle timer to track the user inactivity and display a warning before session times out. Also allow the user to renew the session by making a Ajax call. Just for reference you can refer these links
link 1
link2
Related
I'm using asp .NET MVC app, and I've configured
<system.web><sessionState mode="InProc" timeout="90" /></system.web>
but It looks like session still valid only 20 minutes instead of 90, why?
How can I make this effective instead of the 20 (default I suppose)
I've checked te idle time in the application pool, it was 20, is that the cause of the timout? If yes, how can I override this from config file?
The configuration you are posting seems correct.
Try to check also your IIS configuration. From this TechNet link:
Open IIS Manager and navigate to the level you want to manage.
In Features View, double-click ASP.
On the ASP page, under Services, expand Session Properties.
In the Time-out field, enter a time-out value in the format hh:mm:ss. For example, enter 00:15:00 for 15 minutes.
In the Actions pane, click Apply.
If you are using Form Authentication keep in mind that it uses his own timeout that can be set as follows:
<system.web>
<authentication mode="Forms">
<forms timeout="90"/>
</authentication>
<sessionState mode="InProc" timeout="90" />
</system.web>
Because IIS restart the pool (including sessions) each x minutes with no activity, configured by the idle timeout in the settings of the pool itself, in the case if user set 90 minutes of session in the app, if there is no activity, IIS can restart the pool before this 90 minutes ends. Example:
Session is 60 minutes configures in app.config
after 30 minutes of idle, the pool recycle itself
Only one person use the app
1.00pm: user connects, he navigates during 10 minutes and then do nothing on the page (for instacne fill a very large form without submitting, and without ajax calls. At this point, user has session "open" untill 1.00am + 10 minutes + 60 minutes configured = 2.10 am
At 1.50 am, he tried to press submit button but it doesn't work because the app pool was recycling at 1.40 (1.10 + 30 min of idle) so user lost session.
If this is possible that user is anole on the app, idle time must be the same of greater than session time.
User authenticates, but is becoming unauthenticated within a minute or minutes. Seems to happen at random, but is within a handful of minutes.
Is there a breakpoint I can set someplace where logout is occurring , or a method of troubleshooting why a user is being logged out?
This doesn't seem to happen on localhost when running the project using VS, but is happening on the remote host after publishing.
Set the session state in IIS or the web.config:
<system.web>
<sessionState timeout="60"/>
...
That sets the timeout to be 60 minutes. You should also lookup session state modes.
In my web application, i often can see, that when i am not doing anything for a few minutes, and then i come back, and refresh the page - i am still being logged in, but my session data is all gone!
On the login() action i am setting up few Session[] objects that are necessary for a page to work correctly. I have no idea why is it doing so, but i need it to log user out whenever it clears his session data.
I have read about setting <sessionState mode="InProc" timeout="20"/> but will this timeout refresh everytime i refresh the page? Or will it run out after 20 minutes from the time i logged in? What if i make this timer bigger than i have on keeping the user online?
Posting back to the server will keep the session alive for longer. It's a sliding expiration. There are two ways to handle from the client, which the client is not aware of this 20 minute timeout:
Create a timer using client javascript that redirects to the logout page when 20 minutes is hit
Whenever a postback happens, check if the session expired (which can be done in a variety of ways, such as checking Session.IsNewSession, see if your objects are lost, etc.) and then redirect to the logout handler before processing the request.
I assume you are using Forms Authentication. Is that correct? If so, you need to have your Forms Authentication ticket's timeout match the Session timeout.
The user stays logged in through a process that is more complicated than it first seems. A cookie is stored in the user's browser that is called the Forms Authentication Ticket. If the user stays idle past the session timeout limit, the server will discard the session. But on the next request, the Forms Authentication Ticket is passed back to the web server. The server validates the ticket, and if it is still valid, the user is logged back in.
As you can see, the user's session is not restored. If you want that behavior, you would have to detect that condition and restore the session yourself.
The solution is to set the Forms Authentication Ticket's timeout to be the same as the Session timeout. You accomplish that in your Web.config file, as explained here:
<system.web>
<authentication mode="Forms">
<forms timeout="20"/>
</authentication>
</system.web>
The timeout value is in minutes. Once the Forms Authentication Ticket's timeout is hit, the user will be logged out. This operates independent from the session's timeout, but if they are the same, they will expire at roughly the same time. If you want to be completely safe, set the Forms Authentication Ticket timeout to be a little shorter than the session timeout. The user will be logged out before their session times out. When they log in again, they will get a new session. The old session will eventually time out on its own.
Try checking this:
Q: In Proc mode, why do I lose all my session occasionally?
A: Please see the "Robustness" section in the "Understanding session
state modes" section of of this article.
Robustness
InProc - Session state will be lost if the worker process
(aspnet_wp.exe) recycles, or if the appdomain restarts. It's because
session state is stored in the memory space of an appdomain. The
restart can be caused by the modification of certain config files such
as web.config and machine.config, or any change in the \bin directory
(such as new DLL after you've recompiled the application using VS) For
details, see KB324772. In v1, there is also a bug that will cause
worker process to restart. It's fixed in SP2 and in v1.1. See
KB321792.
Source - http://forums.asp.net/t/7504.aspx/1
Due to the complex business logic, I had to implement myself the authentication. I'm storing the authentication with:
FormsAuthentication.SetAuthCookie(identifier,false);
The False is to indicate that we don't want to have persistent cookie
I've to also store in session some informations(one information that the user has to enter to login, indicating for which set of data he wants to access).
I'm storing those data through model binder.
It's working fine most of the time. But sometime after an inactivity period, we are still logged but we don't have any data in session.
I would like that the duration of my session is the same than the login session, to avoid this kind of "I'm logged but I've lost some data in the session".
I don't need/want to have a persistent connection.
How should I proceed to have this system?
I believe the FormsAuthentication uses its own timeout. You can configure your web.config accordingly:
<system.web>
<authentication mode="Forms">
<forms timeout="50"/>
</authentication>
<sessionState timeout="50" />
</system.web>
In fact, There was a Session timeout by default in the IIS Application pool, so, to avoid this problem:
Go on IIS Manager
Go on the ServerName/Application Pools tab
Right click on the concerned application pool
Click on Advanced Settings,
In the section "Process Model", put an higher value in the "Idle Time-out"(this is in minutes
Click on OK
Restart the application pool
For me, this + the Yannis config(setting the same value for the form timeout+session state timeout) worked.
I'm running a website using ASP.NET 2.0. Every now and then (10+ times per day on 100+ users daily) I receive this error: Forms authentication failed - ticket supplied has expired.
Here's my web.config snippet:
<authentication mode="Forms">
<forms name=".CLLSAUTH" loginUrl="login.aspx" protection="All" path="/" timeout="60" />
</authentication>
I've looked at several solutions, someone mentioned the session timeout, but it's also 60 minutes in my config. Two more things, I'm not running a webfarm, and the app is not being recycled around the time the error occurs.
Any clues?
I'm not sure what your question is... In this case, when a user has their browser open for more than an hour, their authentication cookie times out. The next time they send a request to the server BAM.
Try adding slidingExpiration="true" to the form element.
That way the timeout restarts every time a user hits the server.
This could possibly also be because IIS recycled your worker process. You'd have to check your logs to see if this happened before somebody caused this error.
If your application is running on different servers, there might be an issue with the machine key in the forms authentication cookie being rejected because it's originated on a different server.
But it doesn't sound like you're running on a web farm from your question.