I am working on developing MVC5 application.
I have used session to store user data.
Below is the code which i am using to store session data
if (Session["UserData"] == null)
{
Session["UserData"] = _objLoginSession;
}
I have also increased Session Timeout in web.config, which is as below
<sessionState mode="InProc" timeout="60">
</sessionState>
My authentication mode is also none
<authentication mode="None" />
But when i run my application, it expires with in 1 - 2 minutes only.
Can anyone please guide me on this?
One reason why ASP.NET session might expire that comes to mind is this: session data is kept in memory since you specified InProc mode, so if you recompile your application in Visual Studio or for some reason your application is restarted you will lose session data. And there are plenty of reasons why your application might get restarted by the web server. Things like changing web.config or some files in the bin folder or your computer starts running on low memory.
All those reasons indicate that you should absolutely never (except while developing) keep session data in memory (InProc).
Related
I have and ASP.NET MVC 5 application where I use the ASP.NET Session to store some objects. By default the session mode was InProc and very soon I noticed that these objects started to intermittently disappear from the session. Apparently something was restarting the app_pool so the whole session was getting cleared. I switched the session mode to StateServer (out of process - ASP.NET State Service) thinking that this will solve my problem completely. What really happened was the objects that I put into the session still disappear, but only less frequently. Apparently StateServer session mode is resistant to app_pool restart, but not resistant to some other things.
So my question is: What could be these other things? What can be causing the ASP.NET Session to clear when the mode is StateServer (stored outside of IIS)?
For the last couple of days I'm trying to resolve a problem in my MVC 5 web application related to the anonymous identification module.
I enabled the anonymous identification by adding the following line to Web.config:
<anonymousIdentification enabled="true" />
The problem is that the cookie used by the module changes every time the browser sends a request:
.ASPXANONYMOUS=6yylwpA5baKlbP-ntBra3pA1vr1y5kXp...
After refreshing the page the cookie changes to:
.ASPXANONYMOUS=s3-AlVJNimP5NrDI1PLWc8RK720RTeNY....
And so on and so forth.
What's interesting is that anonymous identification works perfectly fine in our test environment and keeps the value of the cookie consistent across multiple requests. But deploying the same code to production results in this strange behavior, so I suspect a configuration issue in IIS. Both environments use IIS 8.5.
Any idea what I'm missing here?
You have likely moved on but I noticed this while in development on some MVC5 applications.
If you use a valid hostname / domain / IP and not 127.0.0.1, it shouldn't recreate the .ASPXANONYMOUS cookie every request.
On a side note, you can do a lot of edits to the anonymous cookie by applying attributes to the configuration.
For example, the following would only set the anonymous cookie for an hour:
<anonymousIdentification
enabled="true"
cookieName=".ASPXANONYMOUS"
cookieTimeout="60"
/>
Link to documentation on the anonymousIdentification element for more info.
I have an ASP.NET MVC 4 web application. Running locally, it works fine, but on the web host (which uses shared hosting), the logged on user is frequently logged out by being redirected back to the home page. In most cases, the user is logged out after performing only a few actions.
The web host suggested that my application could be using up too much memory but I used a program to profile the memory usage and I confirmed that it wasn't using excessive amounts of memory - in fact the application seems to use a fraction of the allocated memory on the web host.
Here is the logon method that is used:
public static Boolean Login(string Username, string Password, bool persistCookie = false)
{
bool success = Membership.ValidateUser(Username, Password);
if (success)
{
FormsAuthentication.SetAuthCookie(Username, persistCookie);
}
return success;
}
In my web host, the forms authentication timeout is set to 60 minutes, so that shouldn't be an issue, right?
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="60" />
</authentication>
and my session state timeout value is also set to 60 minutes:
<sessionState mode="InProc" customProvider="DefaultSessionProvider" timeout="60">
Based on the answer here, I added this line also, which didn't seem to solve the issue:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps"></machineKey>
Any ideas to what the problem might be and what I can do to solve the problem?
Your sessions are not timing out. The IIS is crashing. Since you are using in memory sessions, every time IIS crashes, your sessions are gone and the user gets logged out. You should check the server's event views and look into details of errors to find out what the error is.
I set my timeout to 2880 in the authentication timeout for web.config and I also set the sessionState before closing system.web
<sessionState timeout="1440"></sessionState>
This will keep the session active for 24 hours.
Well I'm totally stumped on this one. Here is the scenario
asp.net mvc3 web application, has been working fine for quite a few months, but I have been going through patches and new releases weekly or so with new functionality. The codebase itself runs on two separate iis7 windows r2 servers. One of these servers, I dont use the standard app pool identity (network service) - I have a specific user, since it pulls some files off a file server, and hence needs specific rights too add/delete from that directory.
On this server, its just started to act crazy with forms authentication 99% of the time in IE9, once or twice I've got to do it on chrome, but chome/ff usually behave themselves no problems.
The problem is as soon as you log in, and go to another page, it keeps responding with a object moved, and redirecting to the login page again. (Sometimes it even does this on logging in) However the session is still valid, because as part of the template, it shows menu items that are based off having the user authenticated, with calls like
Context.User.IsInRole(xxxx)
Request.IsAuthenticated
I've fiddled it, and cookie sessions seem to be fine, everything is being set as it should.
However, if I do a complete iisreset, ie9 will work for about 5 minutes, then it just fails for every request, and redirects back to the login page.
I'm not using iframes at all in the web application, and my web.config settings are
<sessionState mode="InProc" timeout="80" />
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="40" slidingExpiration="true" cookieless="UseCookies" />
</authentication>
Time sync has been checked, and both client(s) and server are within 1 second of each other.
So at this stage, I'm stuck, I don't know where to go to troubleshoot further, or anything else I can try. I can remotely debug the server, if need be.
When I test locally on my dev box, I'm not seeing any issues.
Thanks,
Cameron
Problem solved. I had the number of worker processes set to 2 for the app pool, and hence it was a lucky pot dip as to which of the 2 worker processes had my validated form cookie/session.
Changed back to 1 and the application works as expected. However I'm going to completely rewrite my session handling and store in a db, so I can increase this worker processes to 4 or so to make the app more efficient.
If you are using FormAuthenticationTicket, check below.
FormsAuthenticationTicket authTicket = new
FormsAuthenticationTicket(1, //version
username, // user name
DateTime.Now, //creation
DateTime.Now.AddDays(5), //<--- THIS Expiration
remember, //Persistent
userdata);
As a user, when I see a "remember me" checkbox, I expect it to remember me -- not just when I close my browser, but when I come back to the site after a week.
So in my ASP.NET MVC application I am considering the following web.config values:
<authentication mode="Forms">
<forms defaultUrl="/" loginUrl="/account/login" name=".ASPXAUTH" timeout="50000000" />
</authentication>
I plan to also have userIsOnlineTimeWindow="20" to still have decent stats about who is online. I also plan to setup a machineKey so that the user isn't kicked off when IIS recycles.
Thoughts on this setup? My biggest concern is that it will hog up resources -- but will it in a stateless MVC app? Isn't that actually related to the sessionState timeout variable as opposed to authentication timeout? And sessionState is no longer relevant in MVC? I've seen conflicting information and am trying to get to the bottom of it.
Also, if I take this approach, I assume that this should also take care of the user who fills out a form for a long time before hitting submit and they lose their work. I've seen posts related to that, but am trying to solve two problems at once (keep alive while viewing the page plus also keep alive for days if I said 'remember me'.
One issue I see is that even if the user doesn't say "remember me" it will still remember them until they close the browser. (To me that's within user expectations.) The other issue is that I may need to perform extra checks on IsApproved and IsLockedOut per http://scottonwriting.net/sowblog/posts/11167.aspx.
Thoughts? Particularly on the system resources issue. Thanks.
FormsAuthentication is stored as a cookie in the client's browser and will not use up any resources by itself. The timeout setting there does not change how long something will be kept in the server's memory or anything to do with the regular session storage.
If you rely solely on the user ID/name you get from FormsAuthentication (HttpContext.User) then yes, there will probably be issues with administering user accounts like you point out. It would be a good practice to look up the actual current user data once per request.