@ -171,8 +171,10 @@ However, there are times that it is beneficial to know the ordering, if you want
@@ -171,8 +171,10 @@ However, there are times that it is beneficial to know the ordering, if you want
To exemplify the above paragraph, let's consider the following security configuration:
====
.Java
[tabs]
======
Java::
+
[source,java,role="primary"]
----
@Configuration
@ -193,7 +195,9 @@ public class SecurityConfig {
@@ -193,7 +195,9 @@ public class SecurityConfig {
@ -217,7 +221,7 @@ class SecurityConfig {
@@ -217,7 +221,7 @@ class SecurityConfig {
}
----
====
======
The above configuration will result in the following `Filter` ordering:
@ -333,8 +337,9 @@ Instead of implementing `Filter`, you can extend from {spring-framework-api-url}
@@ -333,8 +337,9 @@ Instead of implementing `Filter`, you can extend from {spring-framework-api-url}
Now, we need to add the filter to the security filter chain.
@ -31,7 +31,7 @@ If it contains a value, it is used as the currently authenticated user.
@@ -31,7 +31,7 @@ If it contains a value, it is used as the currently authenticated user.
The simplest way to indicate a user is authenticated is to set the `SecurityContextHolder` directly:
.Setting `SecurityContextHolder`
====
[tabs]
======
Java::
@ -66,7 +66,7 @@ Here, we use `TestingAuthenticationToken`, because it is very simple.
@@ -66,7 +66,7 @@ Here, we use `TestingAuthenticationToken`, because it is very simple.
A more common production scenario is `UsernamePasswordAuthenticationToken(userDetails, password, authorities)`.
<3> Finally, we set the `SecurityContext` on the `SecurityContextHolder`.
Spring Security uses this information for xref:servlet/authorization/index.adoc#servlet-authorization[authorization].
====
To obtain information about the authenticated principal, access the `SecurityContextHolder`.