Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is the internal filter of spring security". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

We often use these two classes when we use spring boot with spring security and oauth3. Many tutorials on the Internet do not tell us what the relationship between them is. Which should be effective if you are working on the same Url (e.g. / api/**) at the same time? What does the internal filter of spring security look like? With these questions, we take them away layer by layer.

What does the internal filter of spring security look like?

Java may go through a lot of filter when processing http requests in normal servelet, such as the following example:

Picture .png

And how does spring security deal with it? see the following figure for details:

Picture .png

You can see from the figure that spring security itself has a proxy class called FilterChainProxy, which also implements the servlet interface. There is a List filterChains inside FilterChainProxy``, and SecurityFilterChain is an interface and a chain, and there are several filter in each chain. Since there is more than one filter chain, there is a http request, and which filter chain or filter chain should process the request (as determined by the url of the request)? In spring security, a request will only be processed by one filter chain, that is, when spring security traverses the collection of filterChains, as long as it finds the filter chain that can handle the request, no other filter chain matches will be performed. As shown below: `

Picture .png

For example, if there is a request, url is: / foo/**, then it will be processed by the first filter chain, and the next two filter chain will be ignored. `

When we introduce spring-security-related packages in spring boot, security creates a default WebSecurityConfigurerAdapter for us by default, which intercepts all http requests (/ *), and the value of this Order is: SecurityProperties.BASIC_AUTH_ORDER. By default, Security also creates some filter for us:

Picture .png

The role of each filter can be found in the spring security documentation.

Of course, you can disable the default by setting security.basic.enabled=false in the configuration file, or you can customize a `@ Bean`` with a lower @ order value of WebSecurityConfigurerAdapter (or WebSecurityConfigurer), such as the following code:

@ Order (SecurityProperties.BASIC_AUTH_ORDER-10) public class ApplicationConfigurerAdapter extends WebSecurityConfigurerAdapter {@ Override protected void configure (HttpSecurity http) throws Exception {http.antMatcher ("/ foo/**").}} if you are working on the same Url at the same time (e.g. / api/**), which should be effective?

If WebSecurityConfigurerAdapter and ResourceServerConfigurerAdapter are present at the same time, and both are configured to handle url: / api/**, the latter will take effect by default. When we write ResourceServerConfigurerAdapter, we basically write:

Picture .png

Why does the latter work, because the default @ order value in WebSecurityConfigurerAdapter is 100 (we can clearly see @ Order (100) on this class), and we added the @ EnableResourceServer annotation to ResourceServerConfigurerAdapter, what is this thing for? One of his definitions is that the @ order value is 3 (ResourceServerConfiguration is referenced in this annotation, and the order value is defined in this class). In spring's system, the lower the Order value, the higher the priority, so the ResourceServerConfigurerAdapter priority is higher than the other one, it will take priority, and the WebSecurityConfigurerAdapter will fail.

If we want WebSecurityConfigurerAdapter to have a higher priority than ResourceServerConfigurerAdapter, we just need to make the @ order value of the former lower than the @ order value of the latter.

Note: every time we declare a * Adapter class, we generate a filterChain. We mentioned earlier that a request (matching url) can only be processed by one filterChain, which explains why the former fails by default when both Adapter are present. We can see which filter chain are in the getFilters (HttpServletRequest request) method in FilterChainProxy and which url are processed, for example:

Picture .png

a. If we configure it in this way, the requestMatcher value is to display No fields to display:

Picture .png

b. If configured in this way, the requestMatcher value is the url: / aa/** to which match is displayed

Picture .png

For specific reasons, see below.

What is the relationship between them?

They belong to different functional modules, the former spring security, the latter is in spring security oauth3. They are both Adapter, and they all generate a filter Chain, and they can cooperate with each other to control the permissions of different Url.

However, this often happens when we write code, when we are doing oauth3, when we put two classes in the project at the same time, we all declare different handling of http url, but ResourceServerConfigurerAdapter will completely overwrite the http configuration information, resulting in that all requests will only be processed in the fitler chain of ResourceServerConfigurerAdapter, resulting in users not knowing what the two are all about.

This is actually caused by unfamiliarity with the configuration of spring security, namely antMatcher () ``and authorizeRequests (). AntMatchers ().

Let's look at two examples:

Example 1:

Picture .png

Picture .png

In the above example, the intention is that / api/* endpoints must be authenticated and have USER permissions; / user/** endpoints need to be authenticated, but the end result is that the configuration information related to WebSecurityConfigurerAdapter does not take effect.

Let's use postman to test this:

Picture .png

Picture .png

From this result, we can see that the endpoint of / user/* is not protected, and the endpoint of / api/* is actually processed by the filter chain generated by ResourceServerConfigurerAdapter.

This is not what we want. What should we do? let's take a look at example 2:

Example 2:

Picture .png

Picture .png

Postman Test:

Picture .png

Picture .png

You can see that the endpoint of / api/ is actually processed by the filter chain generated by ResourceServerConfigurerAdapter. The endpoint of / user/ is also protected, but this time it is processed by the filter chain generated by WebSecurityConfigurerAdapter.

Let's take a look at the explanation on stackoverflow:

Picture .png

It basically means that antMatcher () ``is a method of HttpSecurity. He only told Spring that I only configured one url that my Adapter can handle, and it has nothing to do with authorizeRequests ().

Then use authorizeRequests (). AntMatchers () to tell you one or more paths specified in antMatchers (), such as executing permitAll () or hasRole (). They take effect when the first http.antMatcher () match occurs.

Therefore, the simultaneous use of WebSecurityConfigurerAdapter and ResourceServerConfigurerAdapter is actually the same as multiple HttpSecurity configurations of spring security, and the principle is pretty much the same.

To use the official example:

Picture .png

1. Configure verification in the normal way

2. Create a WebSecurityConfigurerAdapter instance containing @ Order to specify which WebSecurityConfigurerAdapter should be considered first.

3. Http.antMatcher indicates that this HttpSecurity is only applicable to URL that starts with / api/.

4. Create another WebSecurityConfigurerAdapter instance. If URL does not start with / api/, this configuration will be used. This configuration takes effect after ApiWebSecurityConfigurationAdapter because it contains a @ order value of 1. 0. No @ Order defaults to being the last to take effect.

This is the end of the content of "what is the Internal filter of spring security". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.