I have an application with claims based authentication and recently I have been having an issue where at random I lose authentication. The application usually gets it's Identity, Claims information from System.Security.Claims.ClaimsIdentity and it authorizes fine. For some reason after clicking around different pages I lose authentication and it seems to be looking in System.Security.Claims.WindowsIdentity and it exits with a null exception as there is now no more authorization information. I am also using IdentityServerV3. I apologise for the lack of specific technical data but was wondering if anyone has ever had this issue. There is no specific time that this does this after as I first thought it might be expiring. It happens very randomly. I have included screen grabs:
This was when I was authorized
and this was 10 seconds later
If you need any further infromation let me know and thanks in advance!
I had similar issue where losing authentication randomly, caused by three reasons I can remember,
1) multiple threading - code was executed by a different thread that doesn't have identity context
2) cookie size exceeded browser limit authentication cookie get chunked when pass back to server
3) identity server hosted in multiple instances and identity server configured to store token in memory.
Regarding your case, my gut feel which might be completely red herring, is the 1) which the thread executing your code 10 sec later is under a different identity context , I would suggest try to verify any path of your code can by multiple threading first, at the mean time check the thinktecture log that can be found in output window if you are using default logging provider to see if anything suspicious
Hope it helps
Related
We have implemented our own oAuth provider and are having an issue when the system runs in a load balanced scenario. When we run with a single server all is well but when we switch the other on we get the following situation:
Token ‘A’ generated on server 1
Token ‘A’ not valid on server 2.
I have done some Googling on this and it seems to be a known issue but can’t seem to find a solution.
Anybody got an idea.
Thanks
You will have to make sure that you do one of:
synchronize the state of your Authorization Server between all load balanced nodes by using a shared cache (e.g. database or file system) or replicates state across nodes using some replication mechanism
your Authorization Server issues tokens that can be inspected by the load balancer to find out to which node it needs to send the validation request
The latter. has the downside that it cannot be used in a high availability scenario.
We have a J2EE application (running on -cough- IE only) that uses JSESSIONID to manage session state between client and server. Some of our customers use a third-party web application (https://mdoffice.sentara.com/) in which the client Javascript onload method calls:
document.execCommand("ClearAuthenticationCache");
This smashes our JSESSIONID cookie in the browser and hence causes the the app server to see subsequent requests from our IE client window as an invalid or timed out session and the user gets kicked out. Our server is OAS/OC4J, but I doubt this it matters: The same basic behavior occurs if I hit the above URL while logged into my online banking.
In trying to research this, I found that most folks are interested in duplicating this behavior in non-IE browsers. I'm interested in how to protect against it. We verified that our session cookies are have domain scoping, but the above command doesn't seem to honor that. We have a lame work-around by which we launch IE with a -noframemerging argument. That's ugly, and also ends up messing with our logic that tries to limit the client to a single login.
I can't find much useful on MSDN, but this article (http://blogs.msdn.com/b/ieinternals/archive/2010/04/05/understanding-browser-session-lifetime.aspx) does make it clear that the above command "...clears session cookies ... for ALL sites running in the current session".
Does anyone know of either:
Obviously preferable: A way to protect our precious session cookies from ClearAuthenticationCache?
Vane hope: A less aggressive alternative to ClearAuthenticationCache that we might tell our customers to communicate to the 3rd party? (Of course, they'd have to do this with any 3rd party that causes this problem. Currently there's just the one.)
Thanks for any help!
Web Users are receiving "Session Expired" when using Acumatica ERP, I have made the following changes to the Web Config file as per documentation:
changed the ReminderRequestPeriod
report Time-out settings
Query Time-out settings
Depending on when/where the users are receiving the timeouts it could be various items.
If the timeout is happening at a consistent duration, then chances are the users are hitting the standard ASP "Session" timeout.
In the web.config file look for the "sessionState" tag and see what the value in "timeout" is. This is in minutes. Increasing this value can increase the amount of time before a users "session" times out.
When modifying this value, you should also look to the "forms..." tag and see what the "timeout" there is set to. This is the duration of the forms authentication duration. These should match or be close or you'll have the authentication timing out before the actual session does.
If you are having random issues (timeouts occurring at various times to various users or multiple users at the same time), one thing to look at is the Eventlog on the server. If there is a problem where the IIS Application pool is recycling (does this by default) or if it is crashing, the end user sessions are not persisted and will show the timeout message.
If it's a recycling issue, you can adjust the the amount of time before it recycles in the Application Pool.
If it's an issue with the pool crashing, there will be an event log showing the crash to help isolate where this is occurring. I had a customer who had this issue recently. After applying some updates they never restarted the server which was causing periodic application pool crashes. Running low/out of memory can do this as well.
These won't guarantee a fix however it might help you isolate the cause of the timeouts
I have similar issue. In my case it worked increasing available memory at web server
Also, remember that if your site was upgraded, you may need to reset your license keys. (you will probably need to contact Acumatica to do this)
We have had clients where their license became invalid after upgrading to a newer version and then only 2 users could log in and if a 3rd user logged in one of the other users received the "Session Timeout" error.
The scenario is as follows. I start an instance of MVC app to debug it. The app uses simple membership and I log in during this run. Then I go back to VS change something and start the instance again. It doesn't happen really often but sometimes at this moment membership starts acting odd. As the app starts, some action, that is behind [Authorize] attribute (to be exact the attribute is on the controller), is called. However the action fails because WebSecurity.CurrentUserId is equal -1 (the action in question just loads some user information based on WebSecurity.CurrentUserId).
If I clear cookies in browser, everything is fine, but I can't expect users to do the same when they encounter the problem.
My colleague explaind to me that it's (probably) happening because my local IIS decided to restart and some of session cookies became invalid, but if this can happen on local instance of IIS, wouldn't it be possible to also happen on the remote server?
Other important fact, the action that fails is called (more like redirected to) by a custom filter that we wrote. This filter is applied to all actions (but doesn't affect the one mentioned). Can this filter somehow make MVC ignore [Authorize] attribute?
I have a dirty workaround for this problem that should work (with this specific app), but I would prefer to prevent the problem from appearing int the first place.
I think this is related to this. Basically when the server gets reset authentication cookies die. They get recreated right away, except my app doesn't really have access to them till the page is reloaded (just like with logging in).
I partially solved the problem described above (a redirect is preformed somewhere on the way) so the application no longer gets stuck. However, if someone was logged in during the time the server restarted and he tries to preform a post after that, his post will not work and he will be redirected to a get action with the same name as the post action (our custom filter is to blame for that). Unfortunately I cannot fix the filter, because I would need user id for that and at the point at which the filter is called, it's still -1.
I guess my question is not too well written and kind of very localized (I should probably rewrite it or reask it), but the underlaying problem is more general than it seems, so let me salvage all the useful information into this answer.
Question 1: There is nothing preventing IIS from having a hiccup on a remote server and restarting the app, so yes this can (and happens) on the remote server (frequency will depend on the app itself and IIS configuration). The problem of disappearing session data seems to be related to the restarts of the app pool rather than the app itself.
Question 2: The custom filter has little to do with the situation. As pointed by Larry, in simple membership authorization is kind of unrelated to session data. If your session data is lost, the user does not stop being authorized, however user data is stored in the session. Without session you don't know who the user is. This information becomes available one action after session data was lost. So loosing session data can lead to a crash of the application or like in my case (where a custom filter depends on user data) to even weirder results.
So if you encounter unexpected disappearance of user data in your app (such as WebSecurity.CurrentUserId becoming -1), it might be worth investigating if your app pool is getting restarted (and why). Setting memory limits for an app pool seems to increase the likelihood of those restarts.
I have an MVC 4 app and am using the default authentication provider. I'm not using persistent cookies.
I don't have any problems in development but when hosted at HostGator, I SOMETIMES get logged off when I try to create a new item (HTTP POST). When this happens, I end up at the log on page like I wasn't authenticated.
HostGator does NOT have the app on multiple web servers so I'm thinking I shouldn't have to worry about machinekey stuff. Am I wrong?
When this happens, I just log in again and create the item again and it will succeed. Once this happens, I can't recreate the issue. I try reopening the browser and even different browsers but creating items will always work. It only seems to happen again if I try much later.
Some additional info, the timeout is set to 2880 (the default for an MVC project), which I know is long but I can't see how it would be related. Still, thought I'd mention it.
So I can't look at IIS logs or event viewer to get any idea what could be happening but I can add more logging to the app. Can anyone provide ideas for what to check or what logging to add to diagnose?
Thanks
EDIT
I realized that I could get to the IIS logs so I compared the POST that succeeded and the one that failed and immediately noticed something.
When I first did the GET to load the Item/Create page/view, the cs-username was populated but when I did the POST to create the item, it was gone. I can see that when I logged in again and was able to successfully create the item, that POST did have the cs-username populated.
Why would it disappear between the GET and the POST? There was a 7 minute delay from the GET to the POST but I can see I logged on 1 minute before the GET so the session was only 8 minutes old when the post happened. I've double checked that I don't have sessionstate explicitly configured so the default should be 20 minutes. I feel like I'm onto something but not sure exactly what.
Might be worth adding Glimpse, although running that on deployed code is kinda risky. It would have the benefit, though, of letting you see what's actually happening on the server. I've never used HostGator, so I can't say for certain, but if they recycle app pools aggressively, that would invalid your login, and explain why the logoff seems to happen randomly.