Chris, Mark,
On 27/05/2021 22:11, Christopher Schultz wrote:
</snip>
</reordered>
What's the primary use-case for these kinds of attributes?
This has been described in detail here:
http://mail-archives.apache.org/mod_mbox/tomcat-users/202104.mbox/ajax/%3Cb9a2a913-f00f-f5bf-ca05-8ea4f8663ca9%40datagis.com%3E
Trying brief:
Basically, it is about getting some user-friendly user related
attributes, like display name, department, phone nuber, Email address
into our applications. Typically, such attributes live in the same user
database, that has already been configured for the Realm for
authentication and authorization. That database might be an SQL database
(DataSourceRealm) or any directory server (JNDIRealm).
Those attributes are often intended for display only (which user is
logged on?). Another common case is sending mails from an application,
which requires a valid From: address of the logged on user.
The Realm will have a new configuration option, e. g.
additionalAttributes, which takes a comma separated field (attribute)
list. The Realm, which already knows how to access that user database,
is the responsible for querying that attributes from the "user table" in
that database (e. g. in JNDI, that is the User's DirContext).
Without knowing anything about SQL or JNDI/LDAP queries, users can
simply configure, what additional user attributes they like to get.
Without that, users need to implement a "session initialized"-hook and
access that user database "manually" and need some knowledge of that
database. Also, credentials for accessing that database must be provided
separately for that hook method.
Unfortunately, Clonable and Serializable have both fallen out of favor
in the Java world because both ideas seem to have some serious issues.
If we pick one versus the other, we may have a lot of push-back.
Too bad. In order to get it bullet proof, my idea is to have a real deep
copy cloning mechanism in Java. That may be even quite slow, since we
could check for a couple of simple but fast cases up front (e. g.
objects that are by design immutable, like String, or some other
commonly used objects, for which we can provide a fast clone with a copy
constructor).
Most of the attributes will likely be strings or be of any of the
commonly used types so, only few object must go through the slow deep
copy clone mechanism.
Actually, my idea was to use Serializable for that. What's the point
with Serializable? Isn't Tomcat using that for clustering/HA as well?
The documentation of Serializable is quite promising...
If we restrict attribute values to Strings, is that too limiting?
I consider that a last resort option, only. Maybe we could agree on
String plus a limited number of well-known, commonly used and (by
design) immutable objects like Number, Boolean, Date (is Date actually
immutable?).
If we return Collections.unmodifiableMap() to return Map<String,String>
that makes things simpler. But how much do we trust
Collections.unmodifiableMap if the underlying data are
security-sensitive? With reflection, is it possible to monkey your way
through the references and swap-out the underlying references? That
might be Bad.
Reflection was another idea. This my slow down things noticeably but, if
we have enough well-known fast-cloning object types defined, that should
not be too bad.
On npm there are likely ten thousands of packages that support deep
copying JavaScript objects. Where's the jpm for Java? Just kidding...
However, the deep copy problem should have been solved already, likely
many many times. Isn't there a common utility function available for
Java somewhere on the Internet? What about Apache Commons? Can we use
these in Tomcat?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
