Describe the bug Some time ago I performed the Spring Security 5.7 migration in our codebase. I noticed that the order of the execution/applying security changed when WebSecurityConfigurerAdapter was removed and the SecurityFilterChain beans were introduced.

I report this phenomena as it could be useful (and time saving) as a guide when migrating from Spring Boot 2.x to Spring Boot 3.x (and from Spring Security 5.x to Spring Security 6.x which is WebSecurityConfigurerAdapter less).

To Reproduce 1. Clone the sample repository 2. Examine the DevSecurity configuration class 3. Run the mvn spring-boot:run in the project root directory 4. Notice the order of the execution in the logs 5. Switch to the migrated branch 6. Examine the DevSecurity configuration class 7. Run the mvn spring-boot:run in the project root directory 4. Notice the changed order of execution

Expected behavior The order is the same or this behavior is explained / documented.

Sample Sample repository can be found here.

It contains two branches, each with a separate README.md: - main branch - migrated branch

Comment From: marcusdacoregio

Hi @rawfg, has this caused any problems in your applications? If so, can you explain more about that scenario?

When reading your README I notice that you mentioned:

secondChain was executed first innerChain of the FirstConfiguration configuration class, despite having @Order(Ordered.HIGHEST_PRECEDENCE) was executed later

They are not really being "executed", instead, it's the order that the beans are being created, which should not really matter because the SecurityFilterChain is going to be invoked based on the configured RequestMatchers. When using WebSecurityConfigurerAdapter, the logs are inside the configure method instead of the bean creation, it is expected that it may vary.

Comment From: rawfg

Hi @rawfg, has this caused any problems in your applications? If so, can you explain more about that scenario?

Hi @marcusdacoregio as far as I remember it caused some problems with migration last year. I need to double check commit history and issues description to confirm that and give more details. Please keep it low profile, I will update ASAP.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: rawfg

Hi @marcusdacoregio I updated the sample repository with the missing HttpSecurity configuration on both branches. To better present the issue I added two controllers (LoginController and HelloWorldController) and a login form. The sample looks like this:

  1. on the main branch, when there are WebSecurityConfigurerAdapter used, is the FirstConfiguration that configures the login form and the InMemoryUserDetailsManager bean. The second configuration has some CORS preflight configuration. When I start the application I navigate to the http://localhost:8080/hello and I'm prompted to provide credentials - after providing I see "hello user" produces by the HelloWorldController. This is the expected behavior.
  2. on the migrated branch, when simple migration (replace WebSecurityConfigurerAdapter configure methods with SecurityFilterChain beans) was done the behavior is different - when I navigate to the http://localhost:8080/hello I see "hello anonymousUser" instead of the login prompt and the entire login security configuration seems totally ignored.

Comment From: marcusdacoregio

Hi, @rawfg. I opened a PR in your repository to show the expected configuration. Basically, you need to define the order of the bean itself instead of the order of the configuration class.

I do not quite understand what you are trying to achieve with the second filter chain, but if you need to customize CORS you can always specify a CorsConfigurationSource bean.