From b5d8626377a1580fe4cda9cf08a09356a436a5c3 Mon Sep 17 00:00:00 2001 From: nima Date: Fri, 13 Sep 2024 23:06:23 +0330 Subject: [PATCH] Fix SecurityContextPersistenceRepository Typo --- .../ROOT/pages/servlet/authentication/persistence.adoc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/modules/ROOT/pages/servlet/authentication/persistence.adoc b/docs/modules/ROOT/pages/servlet/authentication/persistence.adoc index 0a43f504664..d6a8072f249 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/persistence.adoc +++ b/docs/modules/ROOT/pages/servlet/authentication/persistence.adoc @@ -197,13 +197,14 @@ image:{icondir}/number_1.png[] Before running the rest of the application, `Secu image:{icondir}/number_2.png[] Next, the application is ran. -image:{icondir}/number_3.png[] Finally, if the `SecurityContext` has changed, we save the `SecurityContext` using the `SecurityContextPersistenceRepository`. +image:{icondir}/number_3.png[] Finally, if the `SecurityContext` has changed, we save the `SecurityContext` using the `SecurityContextRepository`. This means that when using `SecurityContextPersistenceFilter`, just setting the `SecurityContextHolder` will ensure that the `SecurityContext` is persisted using `SecurityContextRepository`. In some cases a response is committed and written to the client before the `SecurityContextPersistenceFilter` method completes. For example, if a redirect is sent to the client the response is immediately written back to the client. This means that establishing an `HttpSession` would not be possible in step 3 because the session id could not be included in the already written response. -Another situation that can happen is that if a client authenticates successfully, the response is committed before `SecurityContextPersistenceFilter` completes, and the client makes a second request before the `SecurityContextPersistenceFilter` completes the wrong authentication could be present in the second request. +Another situation that can happen is that if a client authenticates successfully, the response is committed before `SecurityContextPersistenceFilter` completes, and the client makes a second request before the `SecurityContextPersistenceFilter` completes. the wrong authentication could be present in the second request. + To avoid these problems, the `SecurityContextPersistenceFilter` wraps both the `HttpServletRequest` and the `HttpServletResponse` to detect if the `SecurityContext` has changed and if so save the `SecurityContext` just before the response is committed.