瀏覽代碼

Merge branch '6.3.x'

Josh Cummings 1 年之前
父節點
當前提交
d2e8c19789

+ 1 - 1
config/src/test/java/org/springframework/security/config/annotation/web/configurers/oauth2/client/OAuth2LoginConfigurerTests.java

@@ -650,7 +650,7 @@ public class OAuth2LoginConfigurerTests {
 	}
 	}
 
 
 	@Test
 	@Test
-	public void configureWhenOidcSessionStrategyThenUses() {
+	public void configureWhenOidcSessionRegistryThenUses() {
 		this.spring.register(OAuth2LoginWithOidcSessionRegistry.class).autowire();
 		this.spring.register(OAuth2LoginWithOidcSessionRegistry.class).autowire();
 		OidcSessionRegistry registry = this.spring.getContext().getBean(OidcSessionRegistry.class);
 		OidcSessionRegistry registry = this.spring.getContext().getBean(OidcSessionRegistry.class);
 		this.spring.getContext().publishEvent(new HttpSessionDestroyedEvent(this.request.getSession()));
 		this.spring.getContext().publishEvent(new HttpSessionDestroyedEvent(this.request.getSession()));

+ 9 - 9
docs/modules/ROOT/pages/reactive/oauth2/login/logout.adoc

@@ -187,7 +187,7 @@ Consider a `ClientRegistration` whose identifier is `registrationId`.
 
 
 The overall flow for a Back-Channel logout is like this:
 The overall flow for a Back-Channel logout is like this:
 
 
-1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `ReactiveOidcSessionStrategy` implementation.
+1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `ReactiveOidcSessionRegistry` implementation.
 2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout.
 2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout.
 3. Spring Security validates the token's signature and claims.
 3. Spring Security validates the token's signature and claims.
 4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated.
 4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated.
@@ -197,13 +197,13 @@ The overall flow for a Back-Channel logout is like this:
 Remember that Spring Security's OIDC support is multi-tenant.
 Remember that Spring Security's OIDC support is multi-tenant.
 This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token.
 This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token.
 
 
-=== Customizing the OIDC Provider Session Strategy
+=== Customizing the OIDC Provider Session Registry
 
 
 By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session.
 By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session.
 
 
 There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database.
 There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database.
 
 
-You can achieve this by configuring a custom `ReactiveOidcSessionStrategy`, like so:
+You can achieve this by configuring a custom `ReactiveOidcSessionRegistry`, like so:
 
 
 [tabs]
 [tabs]
 ======
 ======
@@ -212,23 +212,23 @@ Java::
 [source,java,role="primary"]
 [source,java,role="primary"]
 ----
 ----
 @Component
 @Component
-public final class MySpringDataOidcSessionStrategy implements OidcSessionStrategy {
+public final class MySpringDataOidcSessionRegistry implements ReactiveOidcSessionRegistry {
     private final OidcProviderSessionRepository sessions;
     private final OidcProviderSessionRepository sessions;
 
 
     // ...
     // ...
 
 
     @Override
     @Override
-    public void saveSessionInformation(OidcSessionInformation info) {
-        this.sessions.save(info);
+    public Mono<void> saveSessionInformation(OidcSessionInformation info) {
+        return this.sessions.save(info);
     }
     }
 
 
     @Override
     @Override
-    public OidcSessionInformation(String clientSessionId) {
+    public Mono<OidcSessionInformation> removeSessionInformation(String clientSessionId) {
        return this.sessions.removeByClientSessionId(clientSessionId);
        return this.sessions.removeByClientSessionId(clientSessionId);
     }
     }
 
 
     @Override
     @Override
-    public Iterable<OidcSessionInformation> removeSessionInformation(OidcLogoutToken token) {
+    public Flux<OidcSessionInformation> removeSessionInformation(OidcLogoutToken token) {
         return token.getSessionId() != null ?
         return token.getSessionId() != null ?
             this.sessions.removeBySessionIdAndIssuerAndAudience(...) :
             this.sessions.removeBySessionIdAndIssuerAndAudience(...) :
             this.sessions.removeBySubjectAndIssuerAndAudience(...);
             this.sessions.removeBySubjectAndIssuerAndAudience(...);
@@ -241,7 +241,7 @@ Kotlin::
 [source,kotlin,role="secondary"]
 [source,kotlin,role="secondary"]
 ----
 ----
 @Component
 @Component
-class MySpringDataOidcSessionStrategy: ReactiveOidcSessionStrategy {
+class MySpringDataOidcSessionRegistry: ReactiveOidcSessionRegistry {
     val sessions: OidcProviderSessionRepository
     val sessions: OidcProviderSessionRepository
 
 
     // ...
     // ...

+ 6 - 6
docs/modules/ROOT/pages/servlet/oauth2/login/logout.adoc

@@ -213,7 +213,7 @@ Consider a `ClientRegistration` whose identifier is `registrationId`.
 
 
 The overall flow for a Back-Channel logout is like this:
 The overall flow for a Back-Channel logout is like this:
 
 
-1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `OidcSessionStrategy` implementation.
+1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `OidcSessionRegistry` implementation.
 2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout.
 2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout.
 3. Spring Security validates the token's signature and claims.
 3. Spring Security validates the token's signature and claims.
 4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated.
 4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated.
@@ -223,13 +223,13 @@ The overall flow for a Back-Channel logout is like this:
 Remember that Spring Security's OIDC support is multi-tenant.
 Remember that Spring Security's OIDC support is multi-tenant.
 This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token.
 This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token.
 
 
-=== Customizing the OIDC Provider Session Strategy
+=== Customizing the OIDC Provider Session Registry
 
 
 By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session.
 By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session.
 
 
 There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database.
 There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database.
 
 
-You can achieve this by configuring a custom `OidcSessionStrategy`, like so:
+You can achieve this by configuring a custom `OidcSessionRegistry`, like so:
 
 
 [tabs]
 [tabs]
 ======
 ======
@@ -238,7 +238,7 @@ Java::
 [source,java,role="primary"]
 [source,java,role="primary"]
 ----
 ----
 @Component
 @Component
-public final class MySpringDataOidcSessionStrategy implements OidcSessionStrategy {
+public final class MySpringDataOidcSessionRegistry implements OidcSessionRegistry {
     private final OidcProviderSessionRepository sessions;
     private final OidcProviderSessionRepository sessions;
 
 
     // ...
     // ...
@@ -249,7 +249,7 @@ public final class MySpringDataOidcSessionStrategy implements OidcSessionStrateg
     }
     }
 
 
     @Override
     @Override
-    public OidcSessionInformation(String clientSessionId) {
+    public OidcSessionInformation removeSessionInformation(String clientSessionId) {
        return this.sessions.removeByClientSessionId(clientSessionId);
        return this.sessions.removeByClientSessionId(clientSessionId);
     }
     }
 
 
@@ -267,7 +267,7 @@ Kotlin::
 [source,kotlin,role="secondary"]
 [source,kotlin,role="secondary"]
 ----
 ----
 @Component
 @Component
-class MySpringDataOidcSessionStrategy: OidcSessionStrategy {
+class MySpringDataOidcSessionRegistry: OidcSessionRegistry {
     val sessions: OidcProviderSessionRepository
     val sessions: OidcProviderSessionRepository
 
 
     // ...
     // ...