-
Notifications
You must be signed in to change notification settings - Fork 222
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
useHeaderCheckChannelSecurity doesn't work for AJAX calls #395
Comments
burtbeckwith
added a commit
that referenced
this issue
Dec 6, 2015
burtbeckwith
added a commit
that referenced
this issue
Dec 7, 2015
…lter. It and stores the request and response in the SecurityRequestHolder, which had been done by RequestHolderAuthenticationFilter but later in the chain. RequestHolderAuthenticationFilter also was the entry point for authentication, and was renamed to GrailsUsernamePasswordAuthenticationFilter. SecurityRequestHolderFilter also wraps the request in a HttpServletRequestWrapper wrapper that is aware of the X-Forwarded-Proto header and returns the correct value from isSecure(), getScheme(), and getServerPort() if the header is present. This is part of the fix for issue #395
burtbeckwith
added a commit
that referenced
this issue
Dec 7, 2015
Added GrailsRedirectStrategy to replaced DefaultRedirectStrategy to build absolute urls when using header check channel security to prevent the container from generating urls with an incorrect scheme. Also copied the commence method from LoginUrlAuthenticationEntryPoint into AjaxAwareAuthenticationEntryPoint to use GrailsRedirectStrategy since its RedirectStrategy is a private and final DefaultRedirectStrategy with no way to change it, and updated LogoutController to use GrailsRedirectStrategy instead of calling a regular Grails redirect.
burtbeckwith
added a commit
that referenced
this issue
Dec 7, 2015
…lter. It and stores the request and response in the SecurityRequestHolder, which had been done by RequestHolderAuthenticationFilter but later in the chain. RequestHolderAuthenticationFilter also was the entry point for authentication, and was renamed to GrailsUsernamePasswordAuthenticationFilter. SecurityRequestHolderFilter also wraps the request in a HttpServletRequestWrapper wrapper that is aware of the X-Forwarded-Proto header and returns the correct value from isSecure(), getScheme(), and getServerPort() if the header is present. This is part of the fix for issue #395
burtbeckwith
added a commit
that referenced
this issue
Dec 7, 2015
Added GrailsRedirectStrategy to replaced DefaultRedirectStrategy to build absolute urls when using header check channel security to prevent the container from generating urls with an incorrect scheme. Also copied the commence method from LoginUrlAuthenticationEntryPoint into AjaxAwareAuthenticationEntryPoint to use GrailsRedirectStrategy since its RedirectStrategy is a private and final DefaultRedirectStrategy with no way to change it, and updated LogoutController to use GrailsRedirectStrategy instead of calling a regular Grails redirect.
Fixed, will be in the next release of 2.0 and 3.0 |
Works fine! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I run Spring Security behind the load balancer I set http header 'X-Forwarded-Proto' sent from load balancer to Grails set to 'http'. In Grails app I set following:
This should set all redirect urls (login success url, etc.) to https even if grails runs on http. However for AJAX login it still uses http. I found someone had similar issue with grails 2:
http://stackoverflow.com/questions/27413217/how-to-get-springsecurity-grails-to-play-nicely-with-a-load-balancer-that-is-ter
The only workaround I found is to set full urls of AJAX callbacks:
Original idea from:
http://stackoverflow.com/a/26275028/607038
I assume this is an issue of Spring Security.
Tags: j_spring_security_logout, j_spring_security_check
The text was updated successfully, but these errors were encountered: