-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When using Spring Security the session gets larger and larger #53
Comments
@tobia This won't answer your question about cleaning up after Spring Security. What we ended up doing was bump up our cookie sizes and cookiecount so that we have a config that is like the following:
On the server side we had to increase the maxHttpHeaderSize in our Tomact server.xml to accommodate the larger cookie sizes. We haven't seen too many exceptions since then. A snippet of the exceptions that we were seeing: |
I'm not sure what's going on with spring security - it shouldn't be stashing additional data in the session if a login fails. Have you tried dumping the contents of the session after each login attempt? you should be able to dump the session contents by iterating the keys of the session object from a controller and printing to console. Look out for the object that stores the current identity - it should be anonymous after a failed login. If that doesn't reveal anything, let me know and I can give you some config options that will log the contents of the session just after the cookies are deserialized. |
The problem is quite simple and silly. To avoid this we should remove 'gsession' cookies from the SavedRequest after spring saves it. |
Here's a pull request but it doesn't fix this issue completely. The session still grows up :( |
Any news regarding this? I've been noticing this same behaviour. Spring Security is probably one of the most used plugins in Grails applications, so I think compatibility with it should be top priority. |
Matias, I posted a work-around for this in another thread. The issue is with spring security's exception translation filter. I'm still working on a "better" fix for this, which will likely be a new exception translation filter that does aggressively store the entire request on access denied. In any case, here's the work-around. It's worked for other users. Strategy:
To remove the exception translation filter, add this to the Config.groovy add this mapping to your URLMappings.groovy If you don't have an ErrorsController.groovy, create one and add this method: In your login page render the redirecturl into a hidden form tag called "spring-security-redirect". spring-security-redirect is a special form param picked up by the authentication handler and performs the redirect after successfully authenticating. Let me know if you run into problems. |
Awesome response Ben, works perfectly. Cheers and thanks for your amazing plugin. |
Glad it worked! I'm leaving the issues open until I have the better fix done... On Thu, Oct 29, 2015, 7:36 AM Matias Radzinski [email protected]
|
Fixed in https://github.com/double16/grails-cookie-session/tree/release/4.0.0 dependencies { 'cookies' were also present in the headers, so removed that header. |
I'm using cookie-session with spring-security and spring-security-ui.
I have the following settings, as instructed:
But the session gets bigger and bigger. For example, just by making a couple of failed logins, the session does not fit on 5 x 2048 cookies anymore and it all bombs out.
How can I tell Spring Security to cleanup after itself?
The text was updated successfully, but these errors were encountered: