SecurityConfig Allow some views bypass login

Vaadin 24.4, Java 22

This code fails with error

Caused by: org.springframework.beans.BeanInstantiationException: 
Failed to instantiate [org.springframework.security.web.SecurityFilterChain]: 
Factory method 'filterChain' threw exception with message: 
Can't configure requestMatchers after anyRequest
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeHttpRequests(auth -> auth
                .requestMatchers("/").permitAll()
                .requestMatchers("/setup1").permitAll()
                .requestMatchers("/setup2").permitAll()
                .anyRequest().authenticated());
        super.configure(http);
        setLoginView(http, LoginView.class);
    }

What is wrong with the above code?

Using VaadinWebSecurity seems to behave different to the basic Spring SecurityFilterChain.

.requestMatchers(“/”).permitAll() in the code is intended to have a view that decides if the system is in new install (setup) mode or normal operation.

I am trying to do some setup of a newly installed system with some setup views before spring security forces the login view.

The problem here is that VaadinWebSecurity.configure() method is configuring its own rules, also setting .anyRequest().authenticated()) as a last step.
So configuration that comes before the call to super.configure() should not set rules for anyRequest().

Thanks for reply, @marcoc_753,

I have looked into the Vaadin configure code and can see the .anyRequest().authenticated()) you pointed too.

How then do I bypass the forced login view for any other view?

As a matter of interest, the code I used was based on Perplexity AI suggestion :grinning:

Oh, it appears the solution here is the @AnonymousAllowed annotation.
How is that related to @PermitAll ?

Permit All includes anonymous users; while anonymous does not include authenticated user.

1 Like

The easy way to remember the meaning of PermitAll is to pair it with RolesAllowed. With RolesAllowed you allow specific roles, and with PermitAll you allow all roles. So these annotations are more about authorization than authentication.