I'm using Spring Security 3.1.0 with Remember Me enabled.
I've noticed that SPRING_SECURITY_REMEMBER_ME cookies appeared 2 or 3 times in client's browser.
Cookies with the same value, but with different path: Path=/, Path=/user,Path=/categories
The app is running in / context, so I don't understand how cookies with other paths created.
It happened more than once, but I didn't succeed to reproduce this behavior.
Any idea, how I've might caused it?
Thanks
Alex
UPDATE:
Spring Security version 3.0.5 to 3.1.0
Related
The Spring Security SAML extension sample application doesn't seem to be compatible with Spring Security 4.2.2 (the latest at the time of this writing). At least not out of the box. Is this due to a compatibility issue between the SAML extension and Spring Security or just something that needs to be tweaked / updated in the sample application?
I've seen this link...
Spring Saml not working with latest Spring Security 4.0.0.RELEASE
...where a commenter says that the SAML extension should be compatible with Spring Security 4, but I can't seem to figure out what changes need to be made to the SAML example application to get it working. Has anyone else figured this out?
Thanks!
I am having an issue with the Spring Security demo by Vladimir. When I change the binding and assertion consumer service to HTTP-POST by default, I get the following error...
IDPSSOFederate.doSSOFederate: Unable to do sso or federation.
com.sun.identity.saml2.common.SAML2Exception: Cannot resolve element with ID xxxx
...as a result of an XMLSignatureException.
I have noticed that OpenAM is trying to redirect me to http://localhost:8080/SSOPOST/metaAlias/idp however in the IdP metadata it is specified as http://localhost:8080/openam/SSOPOST/metaAlias/idp.
Obviously I am getting a 404 error but I can't work out why it is redirecting me to an SSOPOST url without the application context.
Scrolling up the logs I can see an earlier getRemoteServiceURL NullPointerException but from what I have read this is part of normal OpenAM logs?
My configuration authenticates fine to OpenAM with the default SOAP settings. Why would HTTP-POST be any different?
Just to let everyone know, I contacted ForgeRock and worked through the issue with them. This problem is related to the following issue: https://bugster.forgerock.org/jira/browse/OPENAM-2644
It is actually a bug in OpenAM which was exposed with the latest Java update (version 1.7.0_25). The temporary solution (until OpenAM 10.2 is released) is to revert back to a previous version of Java.
Reverting to Java version 1.7.0_21 fixed the issue for me.
I have tried many ways to use the httponly flag to prevent XSS attack, but all failed.
Common way is to set use HttpOnly=true in context.xml
For test the result: in the java code set two test parameters in the cookie and in front jsp file include javascript to alert thedocument.cookie, the two test parameters set in java code are get and show in the alert.
Java code:
Cookie cookie = new Cookie("httponlytest","testsss");
response.addCookie(cookie);
Cookie cookie1 = new Cookie("testhttponly","successfu");
response.addCookie(cookie1);
javascript in jsp file:
alert("cookie------------"+document.cookie);
Is there anything i did wrong?
If you know how, it would be very helpful.
For others who do not know HttpOnly:
HttpOnly=true is a relative new attribute to make a cookie in the browser inaccessible to JavaScript.
So it is a browser-only security (XSS) technique to prevent accessing JSESSION_ID (hijacking java sessions) and such.
So you could always set the HttpOnly attribute in the Cookie itself. For the Java session ID it is now default I think, at least it should be.
<Context useHttpOnly="true">
This seems to work only for JSESSIONID. I just found this in SO.
Recently I was dealing with http-only=true cookies. During my research i found that Mozilla and Chrome do not allow java applets to use http-only=true cookies. I was getting issue in accessing the JsessionidSSO cookie. During my research on bugs of JAVA i found this bug
While in IE there is no issue in reading the cookies as IE has provided InternetGetCookieEx() API's to access http-only cookies and added the flag INTERNET_COOKIE_HTTPONLY available only IE8 and above versions. So the problem of accessing the http-only cookies still not solved as java proposed the fix in java 7 update 40 while the current version is java 7 update21.
I m using spring security core plugin 1.2.7.2 and spring security ui 0.2 versions for my application.
I couldn't log on using the credentials I created. The new user is in the database. I looked around I read about double encryption password issues going on between core and ui plugin. The issue is still persisting. I got it worked by commenting the beforeInsert/beforeUpdate methods in the User Domain class. I was wondering if the issue is fixed in the new version?
Is there a different workaround for this? Please advice
Thanks much
There's a setting for this in the latest release (0.2) - see the grails.plugins.springsecurity.ui.encodePassword setting in the "Password Encryption" section in section 10 of the docs: http://grails-plugins.github.com/grails-spring-security-ui/docs/manual/
I have a web app running on glassfish 3.1.1 with struts2 an spring.After i implemented struts2 ssl plugin i had some problems related to jsessionid cookie. The problem was that if i wag going directly to https the cookie was not generated, and i have to ask for http version of the page and then struts2ssl plugin redirects me to https and everything was ok. The second problem is that i decided that after the user had logged in to regenerate the session id (in order to prevent session fixation) and the new session id was nor written to cookie. With all these i decided to use url appended jsessionid, which solved those 2 problems. As you expected there is another problem here, and this is that if i try to access the app via http://myServer:8080/MyApp , the jsessionId is appended correctly, but if the same app is accessed via a glassfish virtualhost the jsessionid isn`t appended anymore.
I suspect a issue with the vhost configuration....
Any ideea?
Thanks,
Adding
<session-config>
<tracking-mode>
COOKIE
</tracking-mode>
</session-config>
into web.xml should do the trick, according to specification