I am facing very interesting issue and I am not sure what can cause this. I am using SSO SAML for authentication to the system and IE11 as the browser to access the application. After some time (e.g. 5 min) the session terminates and it is renewed and it is a background process. Somehow only in IE, the session is not renewed until I maximize the browser and do some user action (after that it works). Other browsers are not affected and everything works in background properly. Do anyone know what can cause the issue in IE that the browser needs to user action?
Related
Sometimes, the login screen will appear if the user clicks the back button and then chooses another link, instead of the content that should be displayed. It's like the application suddenly thinks the user is not authenticated. The user then has to re-authenticate to continue browsing. This happens while the user is actively browsing, so no timeout should occur, and after authenticating, the content is shown (so it's not an authorization problem).
This problem is unfortunately quite difficult to reproduce. The user who has experienced the problem most often is using Windows XP with IE 7, but the problem has also appeared with Windows XP and IE 8. I can't seem to reproduce the problem on Windows 7 with IE 9 or Chrome 18, but because the problem is difficult to reproduce, I can't say confidently that the problem is browser or browser version dependent.
Our ASP.NET MVC 3 app uses Forms Authentication with role information stored in a SQL Server database, and membership information in Active Directory. Hosting environment is IIS 7.5 on Windows 2008 R2.
Has anyone else seen this problem, and know of a workaround?
On the server, I guess that you are using a custom IPrincipal which you need to reattach to the request thread for each request? Are you doing this in an HTTPModule or in global.asax? What page event are you hooking into to authorize the thread?
I have noticed differences in authentication being available in different runtime contexts dependent on which event I use. I now always use OnAuthorizeRequest and check that application.Context.User != null.
But the symptoms you are describing sound more like the authorization cookie is missing from the request intermittently.
Add some debug logging for each request and monitor cookies and authorization to see if you can detect the conditions that cause it.
We have a client that wants to lock down thier pc's to only use our web application.
So I've enabled content advisor to only access this site. However it seems to lose the login session and keeps throwing the user back to the login screen. When I disable content advisor the app runs as it should.
Has anybody exprecienced this before, and can anybody help me solve this.
The pcs are Windows XP using ie8
Cheers
I use Devise in my Rails 3.1 application to manage sessions. In Safari and Firefox, the user is correctly prompted to login if he attempts to access a page that requires authorization. However, in Internet Explorer (versions 7 and 8), the user is correctly redirected to the login page, but logging in does nothing.
In other words, the username and password are correct, but it appears as if Internet Explorer can not set the session. Cookies are enabled for IE as well.
Has anyone experienced any similar session issues with IE? I just need to know where to look. I have already fought through IE's inability to handle pushState, it seems like IE is pretty difficult to code for.
Internet Explorer 9 seems to work fine.
Crossbrowser pushState with hashbang fallback: History.js.
AJAX requests without the XRSF token destroy the devise session, maybe IE is messing this one up with your code.
Firefox has a feature to restore session cookies after restart (either after crash or if user has set "restore session" option) and that's causing a lot of problems (for example: Firefox session cookies).
However some sites, most notably Gmail, somehow don't have this problem. After it restores session Firefox won't sign you back in Gmail, you'll have to enter user/pass again. (although, I am not quite sure if Gmail uses session cookies at all)
Is there a way for server application "prevent" browser from restoring session cookies? Or is there some way to know that you are in restored session?
Ok, to answer my own question...
According to Can firefox restore a secure session after an add-on installation? and the page it links to http://kb.mozillazine.org/Browser.sessionstore.privacy_level there's a Firefox setting 'browser.sessionstore.privacy_level' which determines what FF session restores saves (can be 0, 1 or 2 - see second link).
Until FF4 it was default to store/restore only non-secure sessions (that's why GMail currently asks you to sign in again - they are using SSL/HTTPS), but in FF4 default setting will be to store ALL sessions - so even secure sessions will be restored by FF.
I want to handle following scenarios in my new web application.
If multiple users log into the application with same credentials, the application should deny access.
Since I have out of process session store, I would be able to make out when this situation happens. So I can deny all requests after first successful attempt. This will however not work if the user instead of logging out of the application, closes the browser. The session will continue to reflect in the store for the period of timeout value.
If a user attempts to open a new browser windows (Ctrl+N), the application should defeat this attempt. Every new page can potentially fiddle with cookies. I want to therefore deny the users the ability to open new window.
How about?
Having a server timer and then track users session. Reset the timer when you get the request back to the server.
Not possible. Ctrl + N is for opening a new browser window and this does not mean that the user is going to visit your site.
Also check out this question which might be of some interest.
How to differ sessions in browser-tabs?