Skip to content
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

SpringSecurityService and tags not working because SCH.getContext().getAuthentication() is null #1026

Closed
codeconsole opened this issue Oct 1, 2024 · 5 comments
Assignees

Comments

@codeconsole
Copy link
Contributor

codeconsole commented Oct 1, 2024

After authenticating, springSecurityService.isLoggedIn() is false because
SCH.getContext().getAuthentication() == null

org.springframework.security.core.context.SecurityContextHolder

@codeconsole codeconsole changed the title SpringSecurityService and tags not working because SpringSecurityService and tags not working because SCH.getContext().getAuthentication() is null Oct 1, 2024
@codeconsole
Copy link
Contributor Author

Seems like a Spring Boot issue securityContextPersistenceFilterDeregistrationBean was not registered

2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter securityRequestHolderFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter securityContextPersistenceFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter logoutFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter authenticationProcessingFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter securityContextHolderAwareRequestFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter rememberMeAuthenticationFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter anonymousAuthenticationFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter formContentFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter exceptionTranslationFilterDeregistrationBean was not registered (disabled)
2024-09-30T20:01:35.413-07:00  INFO 10073 --- [  restartedMain] o.s.boot.web.servlet.RegistrationBean    : Filter filterInvocationInterceptorDeregistrationBean was not registered (disabled)

@codeconsole
Copy link
Contributor Author

codeconsole commented Oct 1, 2024

those messages are incorrect because the filter is correctly registered. I isolated the issue in that it occurs only inside a template. It works everywhere else This is not a bug with the plugin, but rather a bug in the filter order of when layouts get rendered.

@jamesfredley jamesfredley moved this to Todo in Grails 7 Oct 1, 2024
@codeconsole
Copy link
Contributor Author

grails/grails-core#13714

@codeconsole
Copy link
Contributor Author

Fixed: Requires running the sitemesh filter after the Spring Security filter chain so the security context is not cleared before the pages is decorated and then making sure Grails triggers buffering by passing the correctly wrapped HttpServletResponse object. Buffering is triggered when response.setContentType() is called.

grails/grails-core@060c935

All that is required is running the latest Grails Sitemesh 3 plugin snapshot.

@github-project-automation github-project-automation bot moved this from Todo to Done in Grails 7 Oct 2, 2024
@codeconsole
Copy link
Contributor Author

Moving the sitemesh filter after security was not best path forward because it ends up with access denied page not being decorated. I came up with a new approach of registering a second site mesh filter inside the filter chain.

It currently requires adding the registration to Bootstrap.groovy and should be added to the plugin configuration if sitemesh 3 is detected.

SpringSecurityUtils.clientRegisterFilter('sitemesh3Secured', SecurityFilterPosition.FORM_CONTENT_FILTER.previous())

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

2 participants