I have a simple question but not able to find solution to it. I have set session timeout of the application in the web.config as :
<sessionState timeout="30" mode="InProc"/>
and its working fine but now I got the requirement that if the user is idle that is, he is not performing any action on the page for one minute his session should get expired. I tried to do it using form authentication as :
<authentication mode="Forms">
<forms loginUrl="~/Login.aspx" timeout="1" slidingExpiration ="false" defaultUrl="login.aspx"/>
</authentication>
But its now working. Any help would be appreciated.
If I have understood the question correctly (see comments by OP) then the problem is that OP wants both slidingExpiration and absoluteExpiration to be active, but with separate timeouts.
This would enable the system require a user to log back in after a certain time of idling, and to require a user to log back in after a different time even if the user was not idling.
Unfortunately this is not supported out of the box using forms authentication. You have to choose either sliding or absolute expiration. Or you have to build a workaround yourself.
You can use a very simple work around by:
Setting the timeout of the session longer than the corresponding forms authentication timeout, and also longer than the desired absolute timeout:
<sessionState timeout="35" mode="InProc"/>
Set forms authentication to use slidingExpiration = true
Create a user logged in timestamp in the session whenever a user logs in:
Session["userLoggedInAt"] = DateTime.UtcNow;
Add an Application_PostAcquireRequestState method to Global.asax:
void Application_PostAcquireRequestState(object sender, EventArgs e)
{
HttpContext context = ((HttpApplication)sender).Context;
if (context.Session != null && context.User.Identity.IsAuthenticated)
{
bool forceLogout = false;
if (context.Session["userLoggedInAt"] == null)
forceLogout = true;
else if (!(context.Session["userLoggedInAt"] is DateTime))
forceLogout = true;
else if (DateTime.UtcNow > ((DateTime)context.Session["userLoggedInAt"]).AddMinutes(30))
forceLogout = true;
if (forceLogout)
{
FormsAuthentication.SignOut();
FormsAuthentication.RedirectToLoginPage();
}
}
}
Disclaimer: Code above was hacked together quickly, may not be fool proof...
Notes:
Setting sliding expiration to timeout after 1 minute seems excessively paranoid. Even a fast user will not be able to finish any significant work in the application during that time. Even my web bank has a longer idle timeout that that. I would recommend a minimum of 5-10 minutes.
Sliding expiration in forms authentication has an interesting feature: The sliding happens by updating the authentication cookie, moving the expiration date forward when the user is active. But this only happens when at least half the expiration time has passed. If you want to guarantee that a user can be idle for 10 minutes without getting logged out, you must therefore set the timeout to be 20 minutes.
Related
I am using this to login:
var f = from b in db.AdminToybias
where b.UserName == a.UserName
&& b.Password == a.Password
select b;
if (f.Count() >= 1)
{
Session["uname"] = f.FirstOrDefault().UserName;
Session["pass"] = f.FirstOrDefault().Password;
Session["role"] = f.FirstOrDefault().Role;
I tried both:
<sessionState timeout="1440" mode = "InProc"></sessionState>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="288000" />
</authentication>
But the application automatically logout user after few mins (don't know exact time). I want to get session unlimited time untill he manually logout.
I tried so many hours but failed. What can i do to achieve this?
I am using Godaddy Hosting.
They are different things. The Forms Authentication Timeout value sets the amount of time in minutes that the authentication cookie is set to be valid, meaning, that after value number of minutes, the cookie will expire and the user will no longer be authenticated - they will be redirected to the login page automatically-. The slidingExpiration=true value is basically saying that after every request made, the timer is reset and as long as the user makes a request within the timeout value, they will continue to be authenticated. If you set slidingExpiration=false the authentication cookie will expire after value number of minutes regardless of whether the user makes a request within the timeout value or not.
The SessionState timeout value sets the amount of time a Session State provider is required to hold data in memory (or whatever backing store is being used, SQL Server, OutOfProc, etc) for a particular session. For example, if you put an object in Session using the value in your example, this data will be removed after 30 minutes. The user may still be authenticated but the data in the Session may no longer be present. The Session Timeout value is always reset after every request.
I have an MVC4 single application page. In the log-in page there are 3 fields: user, password and "remember me" checkbox.
The C# login code is this:
if (WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe))
{
FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);
return Json(new { success = true, redirect = returnUrl });
}
else
{
ModelState.AddModelError("", "The user name or password provided is incorrect.");
}
I want to do this:
If a user logs in with "remember me" true - The cookie will stay until the user logs off.
If the user logs in with "remember me" false - The cookie will expire after 3 hours.
In web.config I have this code:
<authentication mode="Forms">
<forms loginUrl="~/" timeout="180" cookieless="UseCookies" slidingExpiration="false" />
</authentication>
<sessionState timeout="180" />
The problem is when the user doesn't touch the page for a short time (10-30 mins usually), and then the user tries to do something in the page - there is an error
"Authorization has been denied for this request."
(Although sessionStation is more than 30 minutes!)
After the user refresh the page - if the cookie hasn't expired yet - everything works fine. But of course I don't want to make the user refresh the page every 15 minutes or so, it's a single-page-application.
So, I tried to change slidingExpiration to "true" and create a ping (with ajax) every 17 minutes and it really stopped the session expiration and the annoying message - but the cookie didn't expired after 3 hours (I logged in with remember me 'false')!
What can I do?
Right click your application pool from IIS management console and look for "Idle time-out(minutes)".
You can adjust the setting to 0 (zero) which effectively disables the timeout so that the application pool will never shut down due to being idle.
I would double check your IIS settings. See what your App Pool Idle Timeout value is set to. By default it's 20 minutes. When the App Pool goes idle (no users accessing the app pool) for twenty minutes, you will loose session state (All data stored in the session will be cleared).
With more users this problem would work itself out, but presuming you are the only person testing, increasing this value to something greater than 180 minutes will prevent the timeout, or you could set the value to zero to disable the app pool idle timeout altogether.
See this answer for information on checking your app pool timeout in IIS Express... https://stackoverflow.com/a/10222419/386856
Do note that a dead app pool can take several seconds to re-spawn. It may be beneficial to increase this value anyways. This will prevent users from having an extremely slow experience if they happen to be the person that's unlucky enough to have to wait for the app pool to restart.
Update
To allow for a change in timeout for users who don't click remember me, you can create a custom attribute or you could modify the FormsAuthentication timeout via C#. Here are good references on setting the timeout via code. https://msdn.microsoft.com/en-us/library/system.web.configuration.formsauthenticationconfiguration.timeout%28v=vs.110%29.aspx and https://msdn.microsoft.com/en-us/library/system.web.configuration.formsauthenticationconfiguration(v=vs.110).aspx If you want the timeout to expire right at 3 hours, even if the user has activity be sure slidingExpiration is false in your web config. If you want the timeout to expire 3 hours after the user's last activity be sure slidingExpiration is true. So before you set the cookie try something like the following (Be sure to check the OpenWebConfiguration path):
System.Configuration.Configuration configuration = WebConfigurationManager.OpenWebConfiguration("/aspnetTest");
AuthenticationSection authenticationSection = (AuthenticationSection)configuration.GetSection("system.web/authentication");
FormsAuthenticationConfiguration formsAuthentication = authenticationSection.Forms;
formsAuthentication.Timeout = System.TimeSpan.FromHours(3);
formsAuthentication.SlidingExpiration = true;
I solved this by just creating my own encrypted cookie which will persist the user's session if present. In an action filter attribute, check if the user's session is expired, check for this cookie. If the cookie exists, verify the information and reestablish the session. If the user doesn't have a session, doesn't have a cookie, or the encrypted credentials are incorrect, redirect the user to the login page. Since everything is handled in the code, there is no guess work on the server settings.
On login with remember me checked:
if (RememberMe ?? false)
{
var authCookie = new HttpCookie(Config.AuthorizationCookie);
authCookie.Values.Add("ID", Crypto.EncryptStringAES(UserSession.Current.Account.ID.ToString(), Config.SharedSecret));
authCookie.Expires = DateTime.Now.AddDays(30);
AuthorizationCookie = authCookie;
}
Response.AppendCookie(AuthorizationCookie);
On page visit without session (done inside an attribute attached to necessary controllers and actions):
_account = UserSession.Current.Account;
// check if there is currently an account in the session
if(_account == null)
{
// check the user authorization cookie for a user id
HttpCookie authCookie = HttpContext.Current.Request.Cookies[Config.AuthorizationCookie] ?? new HttpCookie(Config.AuthorizationCookie);
if (authCookie.HasKeys && !String.IsNullOrEmpty(authCookie["ID"]))
{
// decrypt the user id for database lookup
_userID = Crypto.DecryptStringAES(authCookie.Values["ID"], Config.SharedSecret);
}
}
Re-establish the session if necessary (done inside a database connection)
// called within a database connection's using statement
protected override void Query(DatabaseContext db)
{
// check the database for the user account
if(_account == null && !String.IsNullOrEmpty(_userID))
{
int tempID;
int? id;
id = int.TryParse(_userID, out tempID) ? tempID : (int?)null;
if(id.HasValue)
{
_sessionRestored = true;
_account = db.User.Find(id);
if(_account != null)
{
_account.LastLogon = DateTime.UtcNow;
db.SaveChanges();
}
}
}
}
Finally restore the session:
if (_account != null)
{
// set the current account
UserSession.Current.Account = _account;
if(_sessionRestored)
{
UserSession.Current.Refresh();
}
}
Your code may look a bit different but that is the crux of how I did it.
I have created a heartbeat mechanism to keep the user's session alive. It will run every 60 seconds. Question is, why not set this to like 15 minutes? Also, why use a heartbeat at all; can't I just set my session expiration time in IIS?
I just want to make it so if a user leaves the page for a half hour or so and goes and gets lunch, that they can come back and their session will still be there when they click submit, so they won't lose any data they might have entered before they left.
$(function () {
// every 60 seconds...
setInterval(KeepSessionAlive, 60000);
});
function KeepSessionAlive() {
$.post("/FACTS/_code/Heartbeat.ashx", null, function () {
//console.log('Session is alive and kicking');
});
}
This can be configured if you are using Session within the .NET framework.
A snippet from http://msdn.microsoft.com/en-us/library/h6bb9cz9%28v=vs.100%29.aspx describes how to set a timeout parameter in your web.config if you are using SessionState
<configuration>
<system.web>
<sessionState
mode="[Off|InProc|StateServer|SQLServer|Custom]"
timeout="number of minutes">
<providers>...</providers>
</sessionState>
</system.web>
</configuration
I am not sure why but only after a certain amount of time, My web application global variables lose value and also the session variables as well. I set in the web config file <sessionState timeout="60" />. This is on my local host i have not put this out on a web server yet, could this be the cause?
with inproc session state, if the app pool recycles or shuts down, your session information is gone. check iis settings for when app pool recycles happen. i believe there is a default to shut down the app pool after 20 minutes of inactivity. there are many other reasons this can happen. if you need session to live beyond the life of your app pool, you should take it out of proc and run in state server or database or something else custom.
In case it runs in IIS, do you have Regular Time Interval (minutes) or Idle Time-out (minutes) to a low value? These settings can be found under Advanced Settings... of your application pool.
This may not solve your problem but you can add the following to the page's OnInit to determine whether or not the session has actually timed out or not:
override protected void OnInit(EventArgs e)
{
// Initialize the base Page class.
base.OnInit(e);
//If the session exists
if (Context.Session != null)
{
// IsNewSession indicates the session has been reset or the user's session has timed out.
if (Session.IsNewSession)
{
// new session, check for a cookie.
string cookie = Request.Headers["Cookie"];
// If there is a cookie does it contain ASP.NET Session ID?
if ((null != cookie) &&
(cookie.IndexOf("ASP.NET_SessionId") >= 0))
{
// Since it's a new session but an ASP.NET cookie exists, the session has expired. Notify the user.
throw new Exception("Your session has timed out. ");
}
}
}
}
If the session has expired and the user clicks on a link to another webform, the asp.net authentication automatically redirect the user to the login page.
However, there are cases when the user does not click on links to other webforms. For example: edit link in gridviews, when using AutoCompleteExtender with textboxes and the application attempts to get the information, and basically, in every case when a postback is done and the event is not automatically handled by the asp.net authentication.
What is the best way to handle these exceptions?
UPDATE: I have just modified the question title: forms authentication timeout, instead of the initial session timeout. Thanks for making me aware of this difference.
UPDATE: I have just created a new question with the specific problem I am facing: How to handle exception due to expired authentication ticket using UpdatePanel?. Surprisingly, I have not found much information about it. I would really appreciate your help.
This is why many systems include timers on the page to give approximate timeout times. This is tough with interactive pages. You really need to hook ajax functions and look at the return status code, which is a bit difficult.
One alternative is to use code based on the following which runs early in the page lifecycle and perform an ajax redirect to a login page. Otherwise you are stuck trying to intercept the return code from ajax and in asp.net where the ajax is done 'for you' (ie not a more manual method like jQuery) you lose this ease of detection.
http://www.eggheadcafe.com/tutorials/aspnet/7262426f-3c65-4c90-b49c-106470f1d22a/build-an-aspnet-session-timeout-redirect-control.aspx
for a quick hack you can try it directly in pre_init
http://forums.asp.net/t/1193501.aspx
Edit
what is wanted are for forms auth timeouts, not session timeouts. Forms auth timeouts operate on a different scale than session timeouts. Session timeouts update with every request. Forms auth tickets aren't actually updated until half of the time goes by. So if you have timeouts set to an hour and send in one request 25 minutes into it, the session is reset to an hour timeout, the forms auth ticket isnt touched and expires in 35 minutes! To work around this, sync up the session timeout and the forms auth ticket. This way you can still just check session timeouts. If you don't like this then still - do the below and sync up the timeouts and then parse the auth ticket and read its timeout. You can do that using FormsAuthentication.Decrypt - see:
Read form authentication cookie from asp.net code behind
Note that this code requires that upon login you set some session value - in this case its "UniqueUserId". Also change the login page path below to fit yours.
protected void Application_PreRequestHandlerExecute(object sender, EventArgs e)
{
//Only access session state if it is available
if (Context.Handler is IRequiresSessionState || Context.Handler is IReadOnlySessionState)
{
//If we are authenticated AND we dont have a session here.. redirect to login page.
HttpCookie authenticationCookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (authenticationCookie != null)
{
FormsAuthenticationTicket authenticationTicket = FormsAuthentication.Decrypt(authenticationCookie.Value);
if (!authenticationTicket.Expired)
{
if (Session["UniqueUserId"] == null)
{
//This means for some reason the session expired before the authentication ticket. Force a login.
FormsAuthentication.SignOut();
Response.Redirect("Login.aspx", true);
return;
}
}
}
}
}
If you're using Forms Authentication, the user will be redirected to the login page when the Forms Authentication ticket expires, which is not the same as the Session expiring.
You could consider increasing the Forms Authentication timeout if appropriate. Even to the extent of using a persistent cookie. But if it does expire, there's no real alternative to redirecting to the login page - anything else would be insecure.
One way to deal with Session timeouts is to use Session as a cache - and persist anything important to a backing store such as a database. Then check before accessing anything in Session and refresh if necessary:
MyType MyObject
{
get
{
MyType myObject = Session["MySessionKey"] as MyType
if (myObject == null)
{
myObject = ... get data from a backing store
Session["MySessionKey"] = myObject;
}
return myObject;
}
set
{
Session["MySessionKey"] = value;
... and persist it to backing store if appropriate
}
}
If you're using a master page or a base page, I would add some logic to one of the events in the page lifecycle to check whether the session is new:
protected void Page_Load(object sender, EventArgs e)
{
if (Session.IsNewSession)
{
//do whatever you need to do
}
}