I've got an app in MVC5 which uses forms authentication. Since rolling it out to a server, after being logged in for 5-10 minutes you are logged out; I would like the login to remain for minimum 1 day.
I suspect this is because the app pool is recycled after 5 minutes of inactivity; unfortunately this is a feature of our hosting and I have no control over it.
I've tried a number of things to work around this:
Set persistent to true on the login call, i.e. forcing it to
"Remember Me".
Set the session state to use a SQL Server database,
with a timeout of 1440.
Set timeout under to 1440 in the web.config.
Forced all three computers that use the site to trust the site in the browser, to make sure the cookie isn't being destroyed.
Set Session.Timeout to 1440 in global.asax.cs (probably redundant when this is also set in web.config)
A few points of background:
The site uses autofac to instantiate the database connection, which interacts with OWIN.
Pretty much everything else regarding the login comes from a standard visual studio setup, meaning I created a new web project and set authentication to forms.
The cookie is still there after being sent to the login screen.
The session is still there (in the database) after being sent to the login screen.
Does anyone know how I might fix this issue?
Asp.net forms authentication cookie not honoring timeout with IIS7
For anyone wondering, the fix here appears to have done the trick. Specifically, setting the machineKey in the web.config.
Related
In my ASP.NET project, I am using Forms authentication. My main.master using LoginStatus control and web.config is set up for "Forms" authentication mode.
Before I log in, the control shows the text as "Login." After I log in, the control shows the text as "Logout." This is expected. However, after clicking around on a few links within the site, the control suddenly starts showing "Login" although I am still logged in. The session is still alive as some of the pages I visit dumps some session information.
Would appreciate if something can point me in the right direction. Regards.
If you are trying to redirect after setting a Session variable using
Response.Redirect("YourPage.aspx");
this may be causing the session token to gets lost, try using the overloaded version of Redirect:Response.Redirect("~/YourPage.aspx", false);
Another problem also may be miss configuration of application pool. If the application pool is configured as a web farm or a web garden (by setting the
maximum number of worker processes to more than one) and if you're
not using the session service or SQL sessions, incoming requests will
unpredictably go to one of the worker processes, and if it's not the
one the session was created on, it will get lost.
The solutions to this is either not to use a web garden if you don't need the
performance boost, or use one of the out of process session
providers.
For more information you can check the link of the original article below: http://weblogs.asp.net/bleroy/Don_2700_t-redirect-after-setting-a-Session-variable-_2800_or-do-it-right_2900_
I have an ASP.NET MVC 3 application that is using windows authentication, configured in IIS 7.5. It prompts the user for their Windows Credentials when they first load the
page.
Now, I want to have the "session" timeout in XX minutes, so that the page
will again prompt them for their credentials if this timeout has elapsed.
I have tried setting the "Session.timeout = XX" in the page_load method of
the page I want to secure.
I notice that the "Session_End" method in Global.Asax does fire, but the
Authentication Ticket appears to "stay valid" even after the Session has
ended.
Is there a way to force the page to prompt again for Windows Credentials at
specified timeouts either by changing configurations in Web.Config or thru IIS?
Please let me know.
You don't have control over the allowed session duration when using Windows Authentication, as this is part of the authentication protocol (Kerberos). There are ways and workarounds, but none of them straightforward.
It seems that forcing a client-side document.execCommand("ClearAuthenticationCache"); might come closest to your needs.
As far as I know there is no easy way to achieve this. I've read on people trying to manually control when 401s are sent but from what I remember, I haven't found any reliable solution.
I've been getting into the (relatively) new Web API that shipped with VS 2012 / MVC 4 / .NET 4.5, and have a custom message handler that handles authentication up and running. I also managed to hook it up to an old .NET 2.0 Membership Provider which was great.
I am now tackling the "authenticate with every HTTP request" issue by using a token in the HTTP request header, which I am comfortable with doing.
Now, for mobile apps when a user opens the app I show a login screen the first time, and don't show it again unless for any reason I get the "Unauthorized" message back. But for my web browser based projects I log in once and the browser (as long as it remains open) will remain authenticated.
What's the best way of forcing a time-out with this sort of authentication? I would prefer to log out based on inactivity, if anyone has done this. This one has me a bit stumped, so any guidance is appreciated :-)
Thanks!
There are two idle timeouts you need to consider.
Server Side idle timeout which expires to token you referred to
Client Side (mobile app) idle timeout which directs the user to re-enter credentials
For #1, You'd have to keep track of which tokens are active, or when they expire, etc... there are multiple ways to do this. How I'd recommend you implement it depends on if your deploying to IIS or Azure and if you'll be scaling out. In general though you want a central location where this information is stored. A DB works, but is relatively slow. Session State could work in Azure as the Session State can be shared across servers via App Fabric, but in IIS, you'd have to use an additinal component to share session state across the servers. Same holds true if you use the HttpRuntimeCache in .NET
It should also be noted that doing such checking server-side is critical so as to prevent someone from hijacking the token you refer to depending on how you ultimately decide to implement things.
For #2, What we did in our iOS app was keep track of the idle timeout. Each time user give input of any kind (e.g. BeginTouch event) in the app, we stop our idle timer and restart it. The timer is configure to take the user to the login screen should the timer fire. This same sort of thing should work well in Android, WP7, etc.
I've got an asp.net application which seems to forget that a user is logged in after a while.
I'm using the membership provider and when opt to "remember" the log in it remembers it during the session. I can even close the browser, restart and come back and it will still be logged in. But after a while it forgets and it seems to do it at any old time. I've once been logged in and when I went to a new page it was logged out.
The other strange things are:
On my development machine it remembers the log in forever. Even after IIS restarts and recompiles it will remember my login as expected.
I have another application on the same server that does remember the login forever. I compared how they handle login and they seem to be identical.
This leads me to believe that the issue has something to do with the server or perhaps something in the application not directly related to the login and membership code. What could I look at?
Edit:
Looked up the cookie using Fiddler and they seem to be ok.
An Authentication cookie created today expires 2 weeks from now, which is how my config is set up:
expires=Mon, 06-Sep-2010 01:47:51 GMT
Edit:
The problem seems to be that the app pool is recycling and the authentication cookie becomes invalid because it can no longer be read as the machine key has changed. The solution was to add a machineKey segment to the web.config and supply a static machine key.
There are two major possibilities.
Cookie expiration. If the cookie expires / goes away, then you are considered logged out.
Cookie invalidation. Login cookies are encrypted based on the machineKey value. If you do not specify a machineKey, a new one is regenerated each time the application pool starts up (or is recycled). That means that any login cookie encrypted with the old machineKey is now invalid, and you will not be considered logged in.
Check to see what the recycle settings are on your application pool in IIS and see if that corresponds with the timing of you not being logged in.
"Remember me" functionality is done using cookies. Cookies can be set with an expiration date. You need to look into how the cookie is being set (Fiddler is good for this, you can inspect the HTTP header when the cookie is set.)
We have a web application running on ASP.NET 3.5. It is viewed by the world as one URL but in reality there are multiple IIS boxes hosting the application controlled by a load balancer.
My problem is that it is a sensitive application with strict security controls around it, and that post authentication if you open another browser to the same application and log in as someone else, the second login overwrites the first logins' session id value in the cookie, and then the first window crashes.
Any idea how I can get around this?
The session ID is placed in the cookie. If another browser window is opened and starts a second session the ID in the cookie will be replaced.
Also, logins should not be controlled via the session cookie. There is a Forms Authentication cookie for that purpose which is more secure as I recall.
Most web applications only allow one session per PC. Try logging into Yahoo Mail, Amazon or Ebay twice on the same machine and you will find the same problem. So ASP.NET is pretty much designed around the idea that there is one login per PC. Although, if you have multiple browsers installed on a machine, you can generally log into apps more than once because each browser keeps its own cookie collection.
edit: You might want to try cookieless sessions, in theory they might allow multiple sessions per PC, although I haven't tried it. But cookieless sessions come with plenty of problems and limitations of their own.
In short, there may be some hacky way to do what you want to do, but it will probably be fiddly and cause other problems elsewhere, because what you are asking for goes against the grain of ASP.NET's core design.