I am using Spring Security 3.1 to handle login authentication, session timeouts and maximum sessions.
Also I am deleting cookies only on logout.
<logout delete-cookies="JSESSIONID" logout-success-url='logout page' />
Also I have set maximum sessions to 1 as of now for testing.
When I open my webpage in browser, it stores jsession id in cookie but the problem starts when I exit and reopen my browser. At this time I cannot find any cookies in the browser, they get deleted that is why I am not getting redirected to welcome page(page after login).
But when I login again, it shows an error message that I am printing:-number of sessions exceeded.
This possibly means that session remains alive on server side but it gets deleted from the cookie on client side due to which I neither see the welcome page nor am able to login on the login page.
What else I need to do so that cookies remain there in the browser till the session times out? I have set session timeout to 10 days
This is normal behaviour. JSESSIONID cookies are only valid for the lifetime of a browser session so are gone when you close your browser. This isn't something you can change.
There is no connection between the browser's perception of a session and the lifetime of a session on the server. Unless you actually log out, the server session is still there until it times out and is removed by the server (10 days in your case). Until that happens, trying to log in again will exceed the number of allowed sessions.
If you want to stay logged in for 10 days, you might want to look at using remember-me cookies rather than the standard servlet container session.
Unless you have a definite requirement for restricting the number of concurrent sessions a user can have, I would avoid using that as it will just cause you problems. You haven't actually shown your configuration for this, but there are really just two options. Either a user can log back in again and the previous session will be marked as expired, or attempting to log in a second time will cause an error until the previous session has timed out, or the user logs out to explicitly invalidate it. The behaviour is controlled by the error-if-maximum-exceeded namespace attribute.
Related
We have created an Identity server 4 application for single sign-on in Asp.net core 2.0. We use the Microsft Identity framework for login and account related pages.
The client applications are created using .net FW 4.7.1 in MVC 5 which are then connect to identity server for single sign-on purposes (used Identity server 3 in client application).
We have a requirement wherein allow users to log in to the application only from a single device at a time. To achieve this, on user login, we create a unique LoginSessionId and store it in DB. On logout, we just make this session-id null.
If someone else tries to login with the same user on another device, we just check if the LoginSessionId has value. If yes, then we give a message informing the user that he's already logged in on another device and if he wants to kill the other session. If he says yes, we let him login and reset the LoginSessionId with a new one. As for the first device login, we have a check-in place to log out that user if his current LoginSessionId does not match the one in DB, so he gets logged out.
We have also set the AccessTokenLifetime and IdentityTokenLifetime of the identity server-client application to 24 hours. Here is the problem we're facing:
When the 24 hours are up after user login, the user gets logged out since the Token must have expired. But the LoginSessionId mentioned earlier is not reset. Thus when a user tries to log back in, we end up showing the message of another user logged in, which is not really the case. Question is,
Is there is any way to raise the token expiry event so that we can clear the LoginSessionId there?
Is there any common place where we can identify the various reasons due to which user gets logged out. Like was it due to token expiry, or because he was idle for a long time (sliding expiry I think), or if he clicked logout himself etc.
What is the max value that we can set for AccessTokenLifetime and IdentityTokenLifetime.
One needs to implement IEventService and IEventSink in Identity Server 4 to get those evnts.
for more details, you can refer to this link.
link
I have an ASP.NET MVC1 site where the user is logged in. He is logged in because he has a cookie ".ASPXAUTH" with a token value in it.
For payments the Users gets redirected to a payment provider. He is redirected to my site when he completed the payment process.
This usually was fine but since the 29th of june I got a lot of users who dont have a cookie when they get redirected to our site.
I cant reproduce this behaviour but I see a pattern: Most users that have lost the cookie have the recent version(20.0.1132.47) of Chrome on Windows.
Has anybody had issues like this in the last couple of days? I have no idea what the reason might be, but I suspect it to be a setting of Chrome that is changed now by lots of users or an addon that changes something.
EDIT
The cookie created by forms authentication is a session cookie. May be some browsers changed the way they detect a session. If I have a session cookie, close the browser and reopen it I still have the cookie.
I'm creating an app that connects to a website, and I don't want the user to need to enter their user credentials every time the app loads. The website returns a session cookie (no expiry date set). Is there any problem with me holding on to that cookie indefinitely? If I just reload it when the app starts, it seems to work.
Thanks!
Each application has its own cookie store. So if there is no expiration on the cookie, and you don't delete it, and the app isn't deleted, then there's no problem with using it for as long as you like.
EDIT Here are some links for more opinions and insight:
Persisting Cookies In An iOS Application?"
iPhone: NSHTTPCookie is not saved across app restarts
My opinion on the matter is that the mobile environment is fundamentally different from the desktop environment. "Quitting" a mobile application is in no way similar to quitting a desktop application. Quitting a mobile application is similar to switching focus on a desktop. You would not expect to re-authenticate every time you pressed Cmd-Tab.
Limiting the life of session tokens is a valuable security precaution, but is correctly implemented on the server side, not the client side. If the server is designed to allow a session to persist indefinitely (because the desktop app is never quit), then there is no reason to not continue the session on a mobile platform in a similar way.
Note that there are other solutions, such as storing the user credentials in keychain so that you can reuse them. This is appropriate in many cases, but it actually is a lower-security solution than persisting the session token indefinitely. If you're going to hold onto an authentication credential forever, it's better that it be a single-purpose token (i.e. a session cookie) rather than a multi-use username and password.
There is no problem in you allowing this cookie to be set, each application has a cookie store from which you can if you need to check the cookies, however I assume that since this is only a session cookie, you will only need to allow it's existence and let the user leverage the web service until such time the user logs out.
I have done this with some of my apps also.
Good luck.
I've got a Rails 3.0.9 application using Devise 1.4.9. I'm having a bit of a problem with the login screens. I think I understand the problem as I've previously fixed a similar issue in a C application. But this time I'm just using devise so it is harder to just fix the source code ...
The basic pattern is I log out of the application, which takes me to a URL such as this: http://10.0.0.25:3000/devise/users/sign_in
I then go home and come back to work the next day, with the above address still open in the browser. I type in the password, but I just get a message saying my session has expired, and I have to re-enter the password.
Making an educated guess, when the user is shown the sign_in page, devise creates a new session which is not currently logged in. When the user submits the page, devise checks the session exists, and then checks the credentials. For security reasons, the credentials will not work for an expired (or unknown) session.
The fix in the C application was to allow a very long timeout for sessions that had never been logged in. Once a session is logged in, it does need to be logged out after an inactivity delay that is relatively short, so just changing config.timeout_in wouldn't be enough.
EDIT: I've noticed by messing around with the timeout set down to 1 minute that the not-logged-in session timeout does not change to one minute (in fact I haven't really noticed whether it has changed at all...) So there must be something else that does this.
Also I realised when a session is not logged in, there is no time stored within the session cookie, so I don't even know exactly how the server determines the session age (I don't have a server-side sessions table).
I have a web application running on Spring Webflow with Spring Security. I have a problem logging out because my app kinda remembers the last page after logging out. When I press back or directly paste the URL to the address bar it can direct the page to the login page, but if I login it will go directly to the last page I went to before logging out. It tends to remember its last state. Below is my application-config snippet.
<security:logout logout-url="/logout.do" invalidate-session="true"
logout-success-url="/logoutSuccess.do" />
Link in my page
#{label.labellogout}
The expired-url attribute
The URL a user will be redirected to if they attempt to use a session which has been "expired" by the concurrent session controller because the user has exceeded the number of allowed sessions and has logged in again elsewhere. Should be set unless exception-if-maximum-exceeded is set. If no value is supplied, an expiry message will just be written directly back to the response.
Sounds like your session is still valid after an Logout. try to make it invalid after logout.
Text is from:
Spring Doc
Not sure that I correctly understand your problem but:
B.1.1.4. session-fixation-protection
Indicates whether an existing session should be invalidated when a user authenticates and a new session started. If set to "none" no change will be made. "newSession" will create a new empty session. "migrateSession" will create a new session and copy the session attributes to the new session. Defaults to "migrateSession".
If enabled this will add a SessionFixationProtectionFilter to the stack. The session fixation protection options on namespace-created instances of AbstractProcessingFilter will also be set appropriately.
Can be read here link