Carsten,
On 5/28/21 01:48, Carsten Klein wrote:
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.
Right. This is literally how every application in the world does things
right now. It always works and always has the information the
application needs :)
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?).
Date is most definitely NOT immutable.
Maybe java.lang.*, any primitive array (especially byte[], which will
certainly be important), and anything that is either Clonable or
Serializable. That pretty much means "Object*" where the "*" means
"well, some kinds of objects".
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.
Honestly, a reflective-attack could just as easily monkey-around with
the principal itself, traversing private members and breaking things in
there. So I'm sorry to have brought-up the idea of messing-around with
an unmodifiableMap. It just moves the problem.
On npm there are likely ten thousands of packages that support deep
copying JavaScript objects. Where's the jpm for Java? Just kidding...
It exists, and it's called Maven Central. Except it's not the cesspool
that is npm.
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?
Deep copy was "solved" with the Clonable interface way back in the
initial release of Java. But it only works if classes actually implement
it. See my note above about its use falling out of favor. If users don't
implement Clonable, then objects of those classes cannot be "cloned".
You might be able to make a copy in some other way, but it's not
universal the way Clonable was supposed to be.
https://jarombek.com/blog/may-15-2018-java-clone
You can also use Serializable as a cloning mechanism: simply serialize
to byte[] and then back again. But it requires the object to be
Serializable, of course, and every object that object refers to, and so on.
The reason Javascript objects are so easy to copy is because the
language was designed to support that kind of thing. Java developers
found Clonable confusing and scary and so they ditched it without
thinking about the consequences. Anyone who says "just use copy
constructors" has never written middleware.
What about Apache Commons? Can we use these in Tomcat?
commons-lang SerializationUtils.clone uses serialization
Evidently, there are some other hacks. Amusingly, some of them use JSON
as an intermediary.
https://www.baeldung.com/java-deep-copy
The Tomcat team, for good reason, have decided to keep dependencies to a
minimum. Where needed, we must "shade" libraries so that they never
conflict with anything a web application might want to load.
So we are likely to opt for something that doesn't require heroics so we
can implement the solution in Tomcat simply, without the need for an
external library.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
