From d2a8e43a55c4095b969d525d4f9835b19471f35d Mon Sep 17 00:00:00 2001 From: Luke Taylor Date: Tue, 9 Jun 2009 00:57:34 +0000 Subject: [PATCH] SEC-1170: Some updates to UserDetails-related Javadoc. --- .../security/core/userdetails/UserCache.java | 2 +- .../core/userdetails/UserDetails.java | 19 +++++++++++-------- .../core/userdetails/UserDetailsService.java | 3 +-- 3 files changed, 13 insertions(+), 11 deletions(-) diff --git a/core/src/main/java/org/springframework/security/core/userdetails/UserCache.java b/core/src/main/java/org/springframework/security/core/userdetails/UserCache.java index 70298e90cf..68a17df0ec 100644 --- a/core/src/main/java/org/springframework/security/core/userdetails/UserCache.java +++ b/core/src/main/java/org/springframework/security/core/userdetails/UserCache.java @@ -23,7 +23,7 @@ package org.springframework.security.core.userdetails; * Implementations should provide appropriate methods to set their cache parameters (e.g. time-to-live) and/or force * removal of entities before their normal expiration. These are not part of the UserCache * interface contract because they vary depending on the type of caching - * system used (e.g. in-memory vs disk vs cluster vs hybrid). + * system used (in-memory, disk, cluster, hybrid etc.). *

* Caching is generally only required in applications which do not maintain server-side state, such as remote clients * or web services. The authentication credentials are then presented on each invocation and the overhead of accessing diff --git a/core/src/main/java/org/springframework/security/core/userdetails/UserDetails.java b/core/src/main/java/org/springframework/security/core/userdetails/UserDetails.java index 5e28faeecf..eb20638582 100644 --- a/core/src/main/java/org/springframework/security/core/userdetails/UserDetails.java +++ b/core/src/main/java/org/springframework/security/core/userdetails/UserDetails.java @@ -31,20 +31,23 @@ import java.util.List; * into {@link Authentication} objects. This allows non-security related user * information (such as email addresses, telephone numbers etc) to be stored * in a convenient location. - *

- * *

* Concrete implementations must take particular care to ensure the non-null * contract detailed for each method is enforced. See * {@link org.springframework.security.core.userdetails.User} for a * reference implementation (which you might like to extend). - *

- * *

- * Concrete implementations should be immutable (value object semantics, - * like a String). This is because the UserDetails will be - * stored in caches and as such multiple threads may use the same instance. - *

+ * Concrete implementations should be preferably be immutable – they should + * have value object semantics, like a String. The UserDetails may be + * stored in a cache and multiple threads may use the same instance. Immutable + * objects are more robust and are guaranteed to be thread-safe. This is not strictly + * essential (there's nothing within Spring Security itself which absolutely requires it), + * but if your UserDetails object can be modified then it's up to you to make + * sure that you do so safely and that you manage any caches which may contain copies of + * the object. + * + * @see UserDetailsService + * @see UserCache * * @author Ben Alex * @version $Id$ diff --git a/core/src/main/java/org/springframework/security/core/userdetails/UserDetailsService.java b/core/src/main/java/org/springframework/security/core/userdetails/UserDetailsService.java index 8dac8f0f87..d2e7cdf172 100644 --- a/core/src/main/java/org/springframework/security/core/userdetails/UserDetailsService.java +++ b/core/src/main/java/org/springframework/security/core/userdetails/UserDetailsService.java @@ -27,7 +27,6 @@ import org.springframework.dao.DataAccessException; *

* The interface requires only one read-only method, which simplifies support * of new data access strategies. - *

* * @author Ben Alex * @version $Id$ @@ -37,7 +36,7 @@ public interface UserDetailsService { /** * Locates the user based on the username. In the actual implementation, the search may possibly be case - * insensitive, or case insensitive depending on how the implementaion instance is configured. In this case, the + * insensitive, or case insensitive depending on how the implementation instance is configured. In this case, the * UserDetails object that comes back may have a username that is of a different case than what was * actually requested.. *