Our site is an ASP.NET MVC site, hosted on Azure and using Azure cache service as session provider. Below is our sessionstate configuration:
The cache in Azure is configured to use sliding expiration, with expiration period of 2 hours
Recently we have an issue of users suddenly being kicked out of the website. There is no exception during that time, except for SecurityException which we throw if user's not logged in. It seems that suddenly user's session is lost and ASP.NET assigns them a new session
As far as we know, since the site is using distributed session state provider, even if the server application pool is recycled, it should not kick out the user/cause session lost
May I know what are the possible causes for this issue? Is it due to distributed cache session provider or due to IIS or due to our site? How should we debug this issue?
Below is our production server IIS application pool setting
Thank you very much
Related
I have an app that uses the ASP.NET Request.AnonymousId to save/load a user context for unauthenticated users. The app is a 4.8 MVC app and it runs on Azure. It appears that intermittently, user information is dropping and it seems to be related to a new AnonymousId being generated. The cookie timeout is 100,000 minutes, 2.5 months and it's highly unlikely a cookie expiration because of the (in)convenient timing. Because it's in an Azure AppService plan that scales, I doubt it's a mismatched machine key, but I'm not certain.
What else could this be?
I use NLog to log to AppInsights, is there a way to get cookie validation errors logged to rule out the machine key issue? I haven't been able to location an event
I have a ASP.NET 4.5 application that runs in an application pool with a particular domain user name and password. It's been working fine for months. A few days ago, there was an Active Directory issue whose details remain unknown to me, but my application users reported around the time of the issue that they were unable to use the application.
The AD issue was eventually "resolved," but the users still could not use the application - until I recycled the application pool.
Before the recycle, I was catching this first-chance exception:
System.Runtime.InteropServices.COMException (0x8007052E): The user name or password is incorrect.
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
After the recycle, I stopped seeing this exception.
The exception itself was being generated by a call to PrincipalContext.FindByIdentity that was failing until I recycled the app pool.
Why on Earth would an app pool recycle change the behavior of PrincipalContext if the app pool credentials didn't change?
App Pools using domain accounts work with the AD domain controllers to validate the domain user.
Since we don't know what happened in your Company with AD we can't definitively say why. We can only assume or conjecture that it appears to have caused this to go wrong.
Resetting the pool after AD was happy again reset this magic. Magic - as in I don't actually know under the hood mechanics but the app pool relies on AD to authenticate the domain user.
Your default app pool recycle time of 29 hours would have eventually fixed it as well. You just did this yourself.
i have a web application built in ASP.NET MVC 4. that is hosted on shared hosting server. On that servers for each package(domain) there is limitation of 100 MB memory for the application pools, if it goes above 100 MB, causing the application pool to restart and session is lost having all your visitors logged out.
I have two options to sort it out :
SessionState = StateServer
Machine Key (From http://aspnetresources.com/tools/machineKey)
I have tried first with no luck(still user logout in two or three requests).
i have tried second but my problem is that i have 2000-3000 existing user if i put the
the machine key into my web.config file its prevents the existing user to login with there current password.
i am using Microsoft ASP.NET Universal Providers for authentication
any help would be appreciated.
thanks
This is probably a duplicate question, but since I can't find the answer in the questions from the past I am going to ask again.
In my ASP.NET application, when I authorize the user, I set the custom FormsAuthenticationTicket. The persistance variable is false, so the authentication cookie should only be valid for current session.
My question is when would this session end? I restart my IIS Express development server, I shut down the dev machine, etc, and the session seems to be still active and the user is authenticated with that cookie.
How come in my VS 2012 + IIS Express environment sessions are immortal?
That's not an issue. You can restart the server and as long as the authentication cookie is still valid, the user is considered logged in. Remember, HTTP is a disconnected protocol.
The cookie will be removed the moment the user logs out and you programmatically remove the cookie or when the user closes his browser.
I'd like to experiment with the out of process session provider in ASP.NET/IIS7 (non-in memory). I understand that then a different process is taking care of my session state, so that I could restart the application domain/w3wp without losing session information.
However, how do I set this up, preferably pretty much transparent to my web application?
Thank you!
Please see Configuring Out-of-Process Session State with the ASP.NET State Service (IIS 6.0):
If you decide to manage session state
by using the ASP.NET state service,
you must determine whether you are
going to maintain session state for a
Web garden or a Web farm. Then you
need to ensure that the ASP.NET state
service (Aspnet_state.exe) is running
and, that it is configured to start
automatically.