In our testing of v25, we see that the aura stylesheet is hitting 403 403 - authorization failed: uri /aura/aura.css . Is there anything known related to springboot4 that we should adjust in our security configuration ?
Actually, VaadinSecurityConfigrer has a permitAll rule for /aura/** and /lumo/**.
Weird that the CSS gets blocked.
Can you set the DEBUG level for Spring Security logs to see if there is additional info?
The filterchain trace looks like this for aura.css:
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Securing GET /aura/aura.css
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking DisableEncodeUrlFilter (1/12)
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking WebAsyncManagerIntegrationFilter (2/12)
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking SecurityContextHolderFilter (3/12)
[nio-8080-exec-8] .s.s.w.c.SupplierDeferredSecurityContext : Created SecurityContextImpl [Null authentication]
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking HeaderWriterFilter (4/12)
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking CsrfFilter (5/12)
[nio-8080-exec-8] s.s.w.c.CsrfTokenRequestAttributeHandler : Wrote a CSRF token to the following request attributes: [_csrf, org.springframework.security.web.csrf.CsrfToken]
[nio-8080-exec-8] o.s.security.web.csrf.CsrfFilter : Did not protect against CSRF since request did not match And
[IsNotHttpMethod [TRACE, HEAD, GET, OPTIONS], Not [Or [eu.olaf.afis.acd.security.internal.RestApiRequestMatcher@4d8d2590, com.vaadin.flow.spring.security.VaadinSecurityConfigurer$$Lambda/0x000075a1bcf028a0@3d46866]]]
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking LogoutFilter (6/12)
[nio-8080-exec-8] o.s.s.w.a.logout.LogoutFilter : Did not match request to PathPattern [POST /logout]
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking RequestCacheAwareFilter (7/12)
[nio-8080-exec-8] o.s.s.w.s.HttpSessionRequestCache : matchingRequestParameterName is required for getMatchingRequest to lookup a value, but not provided
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking SecurityContextHolderAwareRequestFilter (8/12)
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking AcdAuthenticationFilter (9/12)
[nio-8080-exec-8] p.PreAuthenticatedAuthenticationProvider : PreAuthenticated authentication request: PreAuthenticatedAuthenticationToken […]
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking AnonymousAuthenticationFilter (10/12)
[nio-8080-exec-8] o.s.s.w.a.AnonymousAuthenticationFilter : Did not set SecurityContextHolder since already authenticated PreAuthenticatedAuthenticationToken […]
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking ExceptionTranslationFilter (11/12)
[nio-8080-exec-8] o.s.security.web.FilterChainProxy : Invoking AuthorizationFilter (12/12)
[nio-8080-exec-8] estMatcherDelegatingAuthorizationManager : Authorizing GET /aura/aura.css
[nio-8080-exec-8] estMatcherDelegatingAuthorizationManager : Checking authorization on GET /aura/aura.css using org.springframework.security.authorization.SingleResultAuthorizationManager@62476d3d
[nio-8080-exec-8] o.s.s.w.a.ExceptionTranslationFilter : Sending PreAuthenticatedAuthenticationToken […] to access denied handler
[nio-8080-exec-8] e.o.a.a.s.i.AcdAccessDeniedHandler : 403 - authorization failed: uri /aura/aura.css, principal …
I’d suggest setting the TRACE level for RequestMatcherDelegatingAuthorizationManager; it should print which rules are evaluated.
EDIT: Never mind. It seems the log message is already printed
It does not ring any bells for me. Can you share your security configuration?
We have below security configuration:
public SecurityFilterChain securityFilterChain(
HttpSecurity http,
AcdAuthenticationFilter acdAuthenticationFilter,
RestApiRequestMatcher restApiRequestMatcher,
AcdAuthenticationEntryPoint acdAuthenticationEntryPoint,
AcdAccessDeniedHandler acdAccessDeniedHandler) {
return http
.with(VaadinSecurityConfigurer.vaadin(), configurer -> {})
.securityContext(
customizer ->
customizer.securityContextRepository(
new RequestAttributeSecurityContextRepository()))
.csrf(csrf -> csrf.ignoringRequestMatchers(restApiRequestMatcher))
.addFilterBefore(acdAuthenticationFilter, AnonymousAuthenticationFilter.class)
.authorizeHttpRequests(
registry ->
registry
// See StaticResourceLocation.java
.requestMatchers(toStaticResources().atCommonLocations())
.permitAll()
.requestMatchers(INDEX_HTML_MATCHER)
.permitAll()
.requestMatchers(ACTUATOR_MATCHER)
.permitAll()
.requestMatchers(restApiRequestMatcher)
.authenticated()
// anyRequest().authenticated() is not allowed here because it closes the chain,
// and VaadinSecurityConfigurer still need to register some matchers afterward.
// Therefore, if added, Vaadin will throw an IllegalStateException with the message:
// Can't configure requestMatchers after anyRequest
)
.headers(
headers -> headers.frameOptions(HeadersConfigurer.FrameOptionsConfig::sameOrigin))
.exceptionHandling(
config ->
config
.authenticationEntryPoint(acdAuthenticationEntryPoint)
.accessDeniedHandler(acdAccessDeniedHandler))
.build();
}
What about restApiRequestMatcher? How does it look like?
It’s a custom class used to match api requests based on some request info. I excluded it from the security configuration, it makes no difference.
I can’t reproduce with a project from start.vaadin.com. Aura CSS is loaded correctly
Any chance the custom filter is blocking the resource somehow?
The best option at this point is to put a breakpoint in RequestMatcherDelegatingAuthorizationManager and find who is rejecting the authorization
Setting a conditional breakpoint for aura.css in RequestMatcherDelegatingAuthorizationManager , it is strange to see that the matcher for the stylesheet ends up being ‘any request’. I would have thought that the Vaadin static resource matcher or something would get to decide here.
btw we are configuring a url-mapping and following the other thread today i put @StyleSheet("context://aura/aura.css") on Application.java. But we had the 403 problem before that already.
we are configuring a
url-mapping
Ah, interesting!
Now I think it is a bug. VaadinSecurityConfigurers applies the urlMapping to some of its static resources. Most likely aura goes into this category, instead of being handled a context relative.
@jorg.heymans do you mind creating an issue on GH? Please specify that vaadin.url-mapping is used, since this is the critical piece of the issue
Sure Using a url-mapping in v25 leads to aura.css being denied · Issue #22899 · vaadin/flow · GitHub
1 Like
Is it possible that a similar fix needs to be applied for custom stylesheets ?
I have @StyleSheet("themes/app/styles.css"), and then src/main/frontend/themes/app/styles.css . In the browser dev console I see that the stylesheet is not loaded, with the same “NS_ERROR_CORRUPTED_CONTENT” as I was seeing for aura.css. Trying to access the stylesheet directly from the browser reveals that Vaadin is treating it as a route.
Using @StyleSheet("context://themes/app/styles.css") did not help either.
Actually, src/main/frontend is not meant to be used with @StyleSheet annotation, since that location is not served by the servlet container itself.
Right, it’s in the class java doc of StyleSheet actually. Apologies for not checking there first.
@StyleSheet("styles.css") // from src/main/resources/META-INF/resources/styles.css
public class Application implements AppShellConfigurator {
...
}
// and using @import in the styles.css:
@import '@vaadin/aura/aura.css';
// your custom styles ...