Hi there,
as already discussed here:
http://mail-archives.apache.org/mod_mbox/tomcat-users/202104.mbox/ajax/%3Cb9a2a913-f00f-f5bf-ca05-8ea4f8663ca9%40datagis.com%3E
I'm implementing an enhancement for querying configurable extra user
attributes through some of the Realm classes from the "user database"
configured for that Realm.
Before starting off, I want do clarify some questions.
The implementation basically of consists two parts. One is to enable the
GenericPrincipal class (and/or TomcatPrincipal interface) to hold these
additional user attributes. The other part is to query these attributes
from the Realm's configured user database an to store these in the newly
created Principal instance.
The second part is quite clear and changes are only local to the Realm
classes. But some decisions must be made for the first part.
The Principal's attributes will be stored in a Map<String, Object> hash
map. Since attributes may come from various sources, using an
Object-typed value seems appropriate to me. That map will also be added
to internal class SerializablePrincipal in order to be persisted properly.
Now, my questions:
1. How to access the Principal's new attributes
Simplest is to provide a getter method, that actually returns the map
(optionally with a read-only parameter):
/**
* The set of additional attributes associated with the user represented
* by this Principal.
*/
protected final Map<String, Object> attributes;
/**
* Returns the user's additional attributes as a Map.
*
* @param readonly
* if <code>true</code>, the returned map is an unmodifiable
* view of the map; otherwise the underlying map is returned
* unchanged
* @return the user's additional attributes as an unmodifiable Map
*/
public Map<String, Object> getAttributes(boolean readonly) {
if (readonly) {
return Collections.unmodifiableMap(attributes);
}
return attributes;
}
/**
* Returns the user's additional attributes as an unmodifiable Map.
*
* @return the user's additional attributes as an unmodifiable Map
*/
public Map<String, Object> getAttributes() {
return getAttributes(true);
}
However, in the jakarta.servlet classes, there are also some entities
that have attributes. There, attributes are accessed by these methods:
Object getAttribute(String name);
Enumeration<String> getAttributeNames();
void setAttribute(String name, Object o);
Would you, for the sake of uniformity, prefer using these more
servlet-spec like methods?
2. Should I add attributes-related public methods to the TomcatPrincipal
interface as well?
According to the documentation of TomcatPrincipal I likely should:
Defines additional methods implemented by {@link Principal}s created by
Tomcat's standard {@link Realm} implementations.
However, this interface seems only being used with GSS (most other
instanceof tests are performed against GenericPrincipal).
So, I guess the attributes stuff should better NOT be added to
TomcatPrincipal?
3. Class UserDatabasePrincipal in UserDatabaseRealm
Although neither documented nor used in Tomcat's shipped standard
tomcat-users.xml, the UserDatabaseRealm supports the additional
attribute "fullname" for a user entry. This makes this Realm a good
candidate for supporting additional user attributes (actually, the
authenticated user's display name was the initial intention for this
enhancement).
The UserDatabaseRealm creates a Principal with an explicitly set
userPrincipal (why? e.g. DataSourceRealm and JNDIRealm don't) of type
UserDatabasePrincipal. The latter does not extend GenericPrincipal class
and so, will not have the new attributes-related methods by default.
However, since Request.getUserPrincipal returns that "inner"
userPrincipal by calling getUserPrincipal(), attributes should be
available for that UserDatabasePrincipal as well.
My Questions:
Why does UserDatabaseRealm pass a userPrincipal of type
UserDatabasePrincipal? Can't we just drop that and do it like JNDIRealm
or DataSourceRealm?
If not, I need to add the attributes-related methods to the
UserDatabasePrincipal as well.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
