Let's review the first type of request, which is an unauthenticated request accessing a public resource. In our TaskAgile app the register page is publicly available. Let's open the browser at http://localhost:8080/register. Once the page finishes loading, you can see the debug log information in the Spring Security output.
Let's go to the part that was logged by o.s.security.web.FilterChainProxy, which looks like the following:
/register at position 1 of 11 in additional filter chain; firing Filter: 'WebAsyncManagerIntegrationFilter'
/register at position 2 of 11 in additional filter chain; firing Filter: 'SecurityContextPersistenceFilter'
As you can see, the /register request was processed by WebAsyncManagerIntegrationFilter and SecurityContextPersistenceFilter. Then, it is a log printed by w.c.HttpSessionSecurityContextRepository. The full path of this class is org.springframework.security.web.context.HttpSessionSecurityContextRepository. The log it printed out is the following:
No HttpSession currently exists
No SecurityContext was available from the HttpSession: null. A new one will be created.
As you might remember in Figure 10.6, it is when a request is processed by SecurityContextPersistenceFilter that SecurityContext is set up. This log is saying that SecurityContextPersistenceFilter tried to load SecurityContext from HttpSession, which did not exist. Therefore, a new SecurityContext would be created.
Then, FilterChainProxy printed out that the request was through HeaderWriterFilter and LogoutFilter:
/register at position 3 of 11 in additional filter chain; firing Filter: 'HeaderWriterFilter'
/register at position 4 of 11 in additional filter chain; firing Filter: 'LogoutFilter'
When the request was processed by LogoutFilter, the filter tried to check if the request matches the logout processing URL. Since it does not, the filter let the request pass. Then, FilterChainProxy printed out that the request reached UsernamePasswordAuthenticationFilter:
/register at position 5 of 11 in additional filter chain; firing Filter: 'UsernamePasswordAuthenticationFilter'
Still, because the path of the request does not match the login processing URL, the filter let this request pass quietly. The request passes RequestCacheAwareFilter and SecurityContextHolderAwareRequestFilter quietly, as shown in the following log:
/register at position 6 of 11 in additional filter chain; firing Filter: 'RequestCacheAwareFilter'
/register at position 7 of 11 in additional filter chain; firing Filter: 'SecurityContextHolderAwareRequestFilter'
After that, the request arrives at AnonymousAuthenticationFilter. Something interesting happened here, as you can see from the following log:
/register at position 8 of 11 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken@d6fc3bc2: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@b364: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS'
Since the request wasn't authenticated by UsernamePasswordAuthenticationFilter, AnonymousAuthenticationFilter created AnonymousAutnenticationToken in SecurityContextHolder so that when the authentication is retrieved through SecurityContextHolder.getContext().getAuthentication(), the result won't be null. And as you can see, the authority granted to this authentication is ROLE_ANONYMOUS. FilterChainProxy later points out that the request arrived at SessionManagementFilter:
/register at position 9 of 11 in additional filter chain; firing Filter: 'SessionManagementFilter'
Because this is an anonymous request, SessionManagementFilter pointed out that the requested session ID is invalid. After that, the request reached ExceptionTranslationFilter. The way this filter works is that it will let the request pass first and it will catch any Spring Security exception that is thrown afterwards. So, when our request went in, nothing happened:
/register at position 10 of 11 in additional filter chain; firing Filter: 'ExceptionTranslationFilter'
The last filter that the request arrived is FilterSecurityInterceptor. As mentioned earlier, this is where the decision of whether a request can proceed or not is made:
/register at position 11 of 11 in additional filter chain; firing Filter: 'FilterSecurityInterceptor'
As you can see from the following log, this filter went through the paths that we have in SecurityConfiguration one by one to find the authorization settings:
AntPathRequestMatcher: Checking match of request : '/register'; against '/error'
AntPathRequestMatcher: Checking match of request : '/register'; against '/login'
AntPathRequestMatcher: Checking match of request : '/register'; against '/logout'
AntPathRequestMatcher: Checking match of request : '/register'; against '/register'
FilterSecurityInterceptor: Secure object: FilterInvocation: URL: /register; Attributes: [permitAll]
...
AffirmativeBased: Voter: org.springframework.security.web.access.expression.WebExpressionVoter@4d1271da, returned: 1
FilterSecurityInterceptor: Authorization successful
...
FilterChainProxy: /register reached end of additional filter chain; proceeding with original chain
Once a matched configuration is found, it asked DecisionManager, which is AffirmativeBased, to decide if the request is allowed or not. As you can see, WebExpressionVoter gave it a positive vote. The authorization then succeeded. After the request passed the Spring Security filter chain, it proceeded with the original chain.
On its way out, the request still went through the filters it passed on its way in. This time, not all filters were interested in processing it. As you can see from the following log information, ExceptionTranslationFilter did nothing because no exception was thrown and SecurityContextPersistenceFilter cleared SecurityContextHolder:
...
ExceptionTranslationFilter : Chain processed normally
SecurityContextPersistenceFilter : SecurityContextHolder now cleared, as request processing completed
In Figure 10.6, we only include the direction of a request on its way in and the order of the filters a request will go through. As you can see from the log output, on its way out, the order of the filters that will process the request is reversed.