You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add note about overriding equals() and hashCode() in custom UserDetails
This commit adds a documentation note explaining the importance of overriding equals() and hashCode() in custom UserDetails implementations.
The default SessionRegistryImpl in Spring Security uses an in-memory ConcurrentMap<Object, Set<String>>, Map<String,SessionInformation> to associate principals with sessions. If a custom UserDetails class does not properly override equals() and hashCode(), user sessions may not be tracked or matched correctly.
I believe this helps developers avoid subtle session management issues when implementing custom authentication logic.
Signed-off-by: Gurunathan <[email protected]>
Copy file name to clipboardExpand all lines: docs/modules/ROOT/pages/servlet/authentication/session-management.adoc
+7Lines changed: 7 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -589,6 +589,13 @@ public class MaximumSessionsPreventLoginTests {
589
589
If you are using a customized authentication filter for form-based login, then you have to configure concurrent session control support explicitly.
590
590
You can try it using the {gh-samples-url}/servlet/spring-boot/java/session-management/maximum-sessions-prevent-login[Maximum Sessions Prevent Login sample].
591
591
592
+
[NOTE]
593
+
=====
594
+
If you are using a custom implementation of `UserDetails`, ensure you override the **equals()** and **hashCode()** methods.
595
+
The default `SessionRegistry` implementation in Spring Security relies on an in-memory Map that uses these methods to correctly identify and manage user sessions.
596
+
Failing to override them may lead to issues where session tracking and user comparison behave unexpectedly.
597
+
=====
598
+
592
599
== Detecting Timeouts
593
600
594
601
Sessions expire on their own, and there is nothing that needs to be done to ensure that a security context gets removed.
0 commit comments