What is the difference between these lines of code:
<forms timeout="5" />
<membership userIsOnlineTimeWindow="5" />
<sessionState timeout="5" />
Thanks a lot.
Forms (FormsAuthention) are used for authentication and when it times out it will logout user. You can 'prevent' timeout by setting SlidingExpiration property to 'true' and it will renew forms ticket on user activity (read request to asp) if needed. This will keep user logged on while he is 'active' on your site.
Membership is used for user validation and userIsOnlineTimeWindow is there to help you track user activity so when it runs out it will set IsOnline property to 'false' for that user. One new thing I found out is that it will also renew forms ticket while users isOnline is set, main difference is that it doesn't renew itself automatically but only when its GetUser() or ValidateUser() methods are run.
When session times out you will lose data found in Session object. That is all.
Note the following behavior:
You set Session timeout = 10 minutes and Forms Authentication timeout = 8 minutes.
The user logs into your site using Forms Authentication.
Both the Session "clock" and Forms Authentication "clock" start running.
Suppose that you keep some info needed for the site's operation in the Session(For example, Session["userData"] = userData;).
The user is idle for 9 minutes.
At 8 minutes the session times out and the user's data is cleared.
At 9 minutes when the user tries to perform some activity on the site, you naively reference the Session["userData"] to get his info. Since it is null he will get error 500 for a null reference.
Conclusion: Keep the forms authentication timeout shorter than the session timeout.
Related
I am developing ASP.Net MVC application.
We have used sessionState mode SQLServer and i have set timeout to 20 minutes.
<sessionState mode="SQLServer"
sqlConnectionString="data source=127.0.0.1;user id=sa;password=sa"
cookieless="false"
timeout="2" />
Code is something like this in web config.
I have also set login page.
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="2880" />
</authentication>
Now when session expires i want to navigate user to login page.
I checked many things but i was unable to understand how it exactly works? and how can i navigate user login page on session expire?
It is working in InProc mode. I used it in same way and user is redirected to login on session expire.
But i am unable to accomplish same thing in SQLServer Mode.
I am unable to understand what i am missing?
I checked Session State and also found that Session timeout handled in SQLServer Mode
Edit :-
I want to redirect user to login page whenever another http request is executed for that session.
Ordinarily the browser has no idea what is going on on the server. Unless an HTTP round trip occurs, it will remember the state of the session from when the page was rendered.
In addition, you session cookie is probably HttpOnly, so there is no way for the page to check for the presence of a session cookie.
One way to accomplish what you want is:
Add a hidden iFrame to your page. Set the SRC of the iFrame to a handler in your web site
The handler doesn't have to do much except return a 200 OK, plus a refresh header set to a few seconds, so that the handler gets continually polled.
context.Response.AddHeader("REFRESH", "2");
Add framebreaker code to your login page
if (top.location != location) {
top.location.href = document.location.href ;
}
When a request for the handler occurs with an expired session, it'll get redirected to the login page via forms authentication; when the login page is returned, it'll break your iFrame and redirect the full window to the login page.
Or, you can do what everyone else does, which is wait for the user to request another page.
For me, changing the timeout value in the web.config file to anything didn't take place, and the reason was there were somehow some leftover old records in the ASPStateTempSessions table in ASPState database. I had to empty the table and only then my web.config changes took place. I wasted an hour trying to search for the cause so hope this helps someone.
So, run this:
delete from ASPStateTempSessions
Difference between InProc and SQLServer mode is that SQLServer relies on MSSQL job to remove the session. It actively doesn't prevent you from login again.
See Session State Providers
SqlSessionStateStore doesn't actively monitor the Expires field. Instead, it relies on an external agent to scavenge the database and delete expired sessions—sessions whose Expires field holds a date and time less than the current date and time. The ASPState database includes a SQL Server Agent job that periodically (by default, every 60 seconds) calls the stored procedure DeleteExpiredSessions to remove expired sessions.
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
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
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.
In an ASP.NET MVC2 app, we have the standard login action...
if (ValidateUser(model.Email, model.Password)
{
FormsAuthentication.SetAuthCookie(model.Email, model.RememberMe);
...
where the second parameter to SetAuthCookie is createPersistentCookie with the following documentation:
createPersistentCookie
Type: System.Boolean
true to create a persistent cookie
(one that is saved across browser sessions); otherwise, false.
We would like to have the persistent cookie expire after 2 weeks (i.e., a user could return to the site within 2 weeks and not be required to re-authenticate. After that time they would be asked to login again).
How do we set the expiration for the persistent cookie?
Can you not do this?
<system.web>
<authentication mode="Forms">
<forms timeout="20160"/>
</authentication>
</system.web>
The timeout is in minutes.
This timeout value is irrespective of whether or not you are creating a persistent cookie. It simply says that if you don't explicitly terminate the cookie (FormsAuthentication.SignOut), it will automatically expire after the given time period.
In other words, if you do:
FormsAuthentication.SetAuthCookie(someMembershipName, false);
Will result in the cookie expiring when:
The user closes the browser, or
The timeout is reached.
As opposed to if you do:
FormsAuthentication.SetAuthCookie(someMembershipName, true);
Will result in the cookie only expiring when the timeout is reached.
HTH
EDIT:
Take from MSDN:
the timeout attribute is described as follows:
Specifies the time, in integer
minutes, after which the cookie
expires. If the SlidingExpiration
attribute is true, the timeout
attribute is a sliding value, expiring
at the specified number of minutes
after the time that the last request
was received. To prevent compromised
performance, and to avoid multiple
browser warnings for users who have
cookie warnings turned on, the cookie
is updated when more than half of the
specified time has elapsed. This might
cause a loss of precision. The default
is "30" (30 minutes).
Note Under ASP.NET V1.1 persistent
cookies do not time out, regardless of
the setting of the timeout attribute.
However, as of ASP.NET V2.0,
persistent cookies do time out
according to the timeout attribute.
In other words, this expiration setting handles the Forms Authentication cookie only.
The Forms Authentication cookie is a client-side cookie, it has nothing to do with other server-side session you may have (ie a Shopping Cart).
That Session is expired with the following setting:
<sessionstate
mode="inproc"
cookieless="false"
timeout="20"