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
Related
I have a web application developed in asp.net
The application has a "logon" portal where I record users logging on. However, I don't really know when they have exited the web application as they could just shut down the browser, rather than using the "logout" option. As IIS keeps track of session variables for a finite period when users logon, I thought a really useful option would be to use my ASP.net application to interrogate IIS for the value of all session variables, thus telling me who is still active via their session variables.
This could be very useful when it comes to dropping in an upgrade to the website and generally looking at the use of the site.
Thanks
session object. But it only tells me about the current user.
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.
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
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 am developing a web app using MVC 3 that is using standard form authentication. It is hosted on a shared hosting. The problem is that sometimes the user authentication state is lost. I get no exception at all. Do you have any clue what can be the cause?
Does authentication has anything to do with session? I am not using Session object at all.
I was of the impression that Authentication using cookie can work in a load balanced environment. Am I wrong?
The session is lost before the 20 minutes timespan.
A couple of things come to mind here:
Is there any pattern to the lost authentications? Meaning, is it always after 20 minutes or is it really seemingly random?
Since you are on shared hosting, do you explictly set your machine keys in your web.config? If you do not and they are set to auto generate, the keys will be different if your application is load balanced. Thus you authenticate on server A and some subsequent request goes to server B, your application will not be able to decode the authorization cookie and 'kick you out'
In a Web farm, you cannot guarantee which server will handle
successive requests. If a user is authenticated on one server and the
next request goes to another server, the authentication ticket will
fail the validation and require the user to re-authenticate. The
validationKey and decryptionKey attributes in the machineKey element
are used for hashing and encryption of the forms authentication
ticket. The default value for these attributes is
AutoGenerate.IsolateApps. The keys are auto-generated for each
application, and they are different on each server. Therefore,
authentication tickets that are encrypted on one computer cannot be
decrypted and verified on another computer in a Web farm, or in
another application on the same Web server. To address this issue, the
validationKey and decryptionKey values must be identical on all
computers in the Web farm.
See here for more information on that second bit.
The session has a time out, if you go past it your session (and authentication) will get destroyed.
You could increase its timeout from web.config or, and this is the way I went, you could make a dummy page you ping with AJAX every few min. The advantage of the latter is that your session will still terminate in a timely enough manner when the user closes his browser, as opposed to staying there for half an hour using resources and preventing Application_OnExit from running.