Hello Rémy, Mark and Michael,
I'm new to the dev list and did not get your recent mails and didn't
figure out how to get them in order to answer. So, I decided to start a
new thread (sorry for that).
I guess, having those attributes with the Principal (aka Principal
metadata) does not make the Principal a data storage. For my mind, even
the Principal's getName() returns kind of metadata, since an application
typically does not really need the logged on user's name in order to
function properly. Much more important are the user's roles, for example.
So, the new read-only(!) attributes map is just a way of dynamically
adding more of such metadata fields. Another way would be to add a
getUserDisplayName() and a new Realm config attribute
'userDisplayNameCol' (e.g. for the DataSourceRealm), and maybe a
getUserMailAddress() method later. However, that's not flexible at all
and many requests from people to extend this scheme may be the result.
So, the dynamic attributes map is the better choice, right? As long as
it remains read-only, also no one can abuse the Principal as data
storage. Also, there is really no need to ever request that, since an
application already has a fully featured data storage around: the
Session's attributes list. It is primarily intended for exactly that:
storing the application's data. So, you could always deny any upcoming
PRs adding write support to the Principal's attributes by referring to
the Session's attributes map.
Providing such metadata through the Principal is new and was not done
before. However, since, more or less, it's just an extension to the
already available getName() method, I guess, it's a quite good idea.
In the Javadoc, of course, we could emphasize more, that this attributes
map is intentionally read-only and will never be writable.
Michael-o and I agreed on having individual PRs for the three parts of
the initial enhancement (TomcatPrincipal/GenericPrincipal,
DataSourceRealm, JNDIRealm). So, I will provide a third PR for the
JNDIRealm after the DataSourceRealm has been merged.
@Rémy: That was the deal/agreement. We do not touch UserDatabaseRealm
and you do not vote against DataSourceRealm and JNDIRealm.
@Remy: Maybe you would feel better about this, if we use a completely
different approach?
We could use the Realm for technically querying those attributes, but
provide them to the application through the Session's attributes map?
We could either put each single attribute directly into the Session's
attributes using a prefixed name like "userAttribute.user_display_name",
or we could add a UserAttributesStore instance (would be a new Tomcat
specific class) under a "userAttributes" name, which has
getAttribute(String name) and getAttributeNames() methods.
However, I guess, implementing this approach is a bit more complicated
than the current one.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
