What's the difference between the two? I'm not so sure but I believe the HttpServletReqest.getSession.invalidate() invalidates the user's session only while the invalidate-session="true" invalidates the session and redirects the user to the defined session-expired page. Please correct me if I'm wrong, I would want to understand this more. Thanks.
invalidate-session is an attribute on the <logout> element and causes the session to be invalidated upon logout (which is the default behavior), but doesn't cauese any redirection itself.
The session-expired page comes into picture if a request contains an invalid/expired session id, in which case the SessionManagementFilter redirects it to a pre-configured URL, which you can set through the <session-management invalid-session-url="..."> configuration. In case nothing is set, no redirection happens.
HttpServletReqest.getSession.invalidate() simply invalidates the session, as you said.
Related
I am using spring security for authentication and in my current implementation when the user logs out, I am invalidating the session and deleting the cookie
what I am looking for is to add a fresh cookie along with old cookie value deletion.
I also happen to see that the cookie is added only once the user is authenticated. Is it possible to add cookies soon after the first page is requested?
Thanks
Fixed it by changing sesssionCreationPolicy to sesssionCreationPolicy(ALWAYS)
I've followed Spring Security's instructions and managed to authenticate my users using JDBC in a Spring Boot project with "Remember Me" feature enabled (and setAlwaysRemember(true)). The "Remember Me" cookie gets created in the client's browser and the Token gets inserted into the "presistent_logins" table without fail.
But here comes the dilemma, When the client closes the browser, the "Remember Me" cookie gets removed automatically, which somehow makes all my effort effectless.
what would be the point of having Remember Me feature, if the cookie which is an essential requirement, gets removed on every browser closed event. Therefore, the user has to do the login all over again.
Here is a picture that shows the remember me cookie has been created after a successful login.
Do I have to take some special measures to make sure that the cookie gets preserved in the browser?
Chrome >>
Firefox >>
It's not the browser who is clearing the remember-me cookie. It's your spring app which tells the browser to clear that cookie (by giving an old expiry time).
So why does spring do that?
Because internally spring is throwing BadCredentialsException. You should debug RememberMeAuthenticationProvider class to make sure why it's throwing that exception.
In my case, the remember-me secret key was different than the one I used in my PersistentTokenBasedRememberMeServices class.
So please debug your application to find out the root cause of it...
Finally had to use normal mode of Remember Me feature (not DB persistence mode) in order to have this working. :(
When I use DB to persist session information, upon closing the browser, the "remember-me" session vanishes somehow!
Spring makes removing cookies on logout entirely painless, you just add
<security:logout logout-url="/j_acegi_logout" logout-success-url="${server.environment.baseUrl}j_spring_security_logout" delete-cookies="USERPREFS"/>
Now, USERPREFS is the name of the cookie in the app that stores information for a specific user, and is set to be a session cookie only. When the user logs out, that cookie is removed, so other users won't have someone else's preferences applied. However, I noticed that in the case of a session timeout, a user could come along to the computer terminal, try to refresh the page, get redirected to the login screen, and now they're back in the app with the previous user's cookie!
Obviously when there is no cookie, the values are being supplied dynamically by the app, but to avoid a few extra db calls, I check to see if the cookie already exists in the request, and use it if it does. I can stop doing this, but it would be nice to just be able to set that cookie to also get removed when the application has to reestablish a new session, especially when the user switches
I believe USERPREFS is logged-in user's preferences. In that case you cannot use the value set in USERPREFS until the user logs-in. If that is the case, you should set the values from user's preferences saved on the server side when the user logs in. That way, though you have USERPREFS cookie, you don't use the value until the user logs in. When the user logs in you set the logged-in user's preferences in the cookie so that currently logged in user's preferences are used.
I am using Spring Security 3.1.x and trying to achieve the following scenario:
a page is secured with isFullyAuthenticated()
the current user is only authenticated with Remember Me, so not fully authenticated
the user navigates to this fully authenticated page - this should not be permitted (and it's not)
however, the user should not get the 403 page - instead, the user should be prompted to login via the Login form
after logging in, the user should be allowed to proceed to the page he previously requested, since now he's a fully authenticated user
My Spring Security config is:
<http use-expressions="true">
<intercept-url pattern="/admin/full_auth_only.html" access="isFullyAuthenticated()" />
<form-login login-page="/login.html" default-target-url="/authenticated.html" />
<logout />
<remember-me key="someAppKey" />
</http>
And I tried to add:
<access-denied-handler error-page="/login.html" />
However, the problem is now that, when visiting the page, I am indeed prompted by the Login form, only the URL doesn't correspond to login; instead it's the URL of the fully authenticated page:
http://localhost:8080/spring-security/admin/full_auth_only.html
Which then breaks the authentication process, which fails when trying to access the (invalid) URL:
http://localhost:8080/spring-security/admin/j_spring_security_check
This should have been:
http://localhost:8080/spring-security/j_spring_security_check
Any help on this is appreciated - I think the usecase is very common and so I would prefer using the namespace support instead of going in a custom direction.
Thanks.
Eugen.
I couldn't reproduce your issue with version 3.1.3.RELEASE of Spring Security. Which version do you use?
Authentication requests are intercepted by the AbstractAuthenticationProcessingFilter that checks if the URL of the request ends with a pre-configured value (that defaults to /j_spring_security_check). Any URL with that ending will trigger an authentication attempt. You can see the related code here.
This means that the URL you said is invalid should in fact be processed without problems.
The code linked above hasn't been changed since very early versions (2.x), so there should be some other issues in your case.
If you could share your configuration and some debug level logs, that would help to reveal what's the real problem.
1.Remove any welcome-file-list if you have in web.xml.
2.Make sure always-use-default-target is not set to false in form-login tag or remove it all together.
3.And make sure you have permitted every one to access your login page. something like this <intercept-url pattern="/login.htm" access="permitAll()"/>
That should work.
it sounds like the cookie was not set, and the following requests sent were all treated as the first requests without a session ID, so spring security asked for login every time even though you had logged in.
If you were using google chrome, and tested the application in your local machine using the localhost address, the cookie might not be set. And it is a known issue with Google chrome.
You can try 127.0.0.1 instead to test. Or try another web browser like Internet Explorer.
I use Spring Security 3 in my JSF2 webapp.
I have a security rule to provide session timeouts:
<session-management invalid-session-url="/faces/paginas/autenticacion/login.xhtml?error=1" />
So that when the session has expired and the user clicks on any link, he is redirected to the login page. In this page I check for the error param, and show a message to the user saying the session has expired.
But I have 2 problems:
(1) When I startup the app the first time (it tries to show the home page), I'm redirected to the login page saying session has expired. I think that this may be happening because the 1st time you run the app, the session is a new one, and Spring Security perhaps "thinks" he has expired (doesn't distinguish betwen a new session and a timeout).
(2) If the session has expired for anonymous users (not yet authenticated), I'm redirected to the login page timeout too. I don't want this behaviour for non-authenticated users, I just want to check the timeouts for authenticated users.
How can I solve both of these problems?
Thank you in advance.
You want to use the expired-session-url property for expired sessions, not the invalid-session-url. They are for two different things.