On Fri, Feb 11, 2022 at 10:10 AM Rémy Maucherat wrote
If we get there, it could include mail addresses, ssn, payment info,
user profile pictures (binary), etc etc.
Also one thing I don't get now is how this became Object
getAttribute(String name) instead of String getAttribute(String name)
? The legitimate examples you gave are text, not binary objects.
Ultimately, all of this is still application data ... Moving it in the
Tomcat realm creates a proprietary behavior, the application is no
longer portable while at the same time the benefit is minimal (saving
a query ?). When logging in, the app should pull all the metadata it
needs, store it in the session.
Yes, it could be that much metadata, so what? And yes, it's all
application data. But that must not be something negative. You may say,
this is up to the application but, isn't it convenient if the realm does
it for you? Tomcat's Request (e.g. HTTPServletRequest) returns all data
POSTed from a client; all that data may be application specific data as
well. Nobody cares...
Again, it's not about saving one query while logging in a user. It's
primarily about
1. not needing to configure an extra connection to the user database
2. not needing much custom code an knowledge/skills of the user database
(SQL, LDAP etc.)
3. getting extra attributes from Tomcat "for free" with 'any' Realm
simply by configuring a list of fields uniformly
As you are correctly saying, point 1. is not that complicated for
DataSourceRealm, as there is a JDBC pool around. Nevertheless, the
application still needs to know the name of the connection (e. g.
"jdbc/userdatabase") and the name of the user table, the column
containing the logon name (what Principal.getName() returns) and the
extra columns to query.
With my solution, all that configuration is "hidden" in the Realm's
configuration. The only new thing is the "userAttributes" config
attribute. No duplicated configuration is required.
What do you mean with 'proprietary behavior'? Why shouldn't the
application be no longer portable? The Realm's configuration always
contains any access data (JNDI resource names, URLs and passwords in
case of JNDIRealm), so it wasn't ever portable at all. If you think
about moving the application between different servers on the same site
(targeting the same user database), the new "userAttributes" should work
from any Tomcat server you use.
Moving between different user databases is also much simpler, since the
whole configuration is centralized at the Realm.
Why do I store Object and not String attributes? Because I can... When
querying a JDBC database or a LDAP server dynamically, you must expect
various different types being returned. We could add a rule, that all
must be Strings or we call the toString() method on each value. But why?
Yes, well, unfortunately, due to more background thinking ...
The purpose of the UserDatabase is to be able to write, so given the
API it is an object database at this point.
In my recent implementation, the AbstractUser got a
/**
* Additional attributes of this user.
*/
protected Map attributes = new HashMap<>();
so, the UserDatabase does not store Object typed attributes, but only
Strings (since XML attributes are strings only). So, I don't understand
why you consider it an object database.
Ok, but ... Your actual use case is the DataSourceRealm, which uses a
DataSource. That DataSource is a JNDI resource which is also available
to the application. Getting a connection from the pool is not
expensive at all, and running an extra query from a prepared statement
is just that. If more state is needed (I believe that will always be
the case), then the difference becomes minimal. Also, the whole data
layout is in the hands of the developer, who then chooses to abuse the
realm backend. So overall in that case, all that you mention is still
best done in the application, replacing the API with something
different (like storing in the session) does not change that and this
is simply about moving a small piece of code from the application to
the container.
Yes, with JDBC and a DataSource it's quite simple to do that in the
application. However, this ends in much custom code required to run
after login. Actually this makes the application not portable (or at
least hard to port).
Believe me, I know what I'm saying. I'm running a software company with
< 20 customers, each having different user databases and needs. Having
tailored code for each of them is something you could call `JAR-hell`
(you know Windows DLL-hell?).
Although I heavily changed my mind on the rest, JNDI/LDAP always
looked to me like the legitimate use case. There's indeed metadata in
there. It could be more difficult to get to it from the app. Maybe
it's less scalable than a DB, and there's no shared connection pool
with the app. So it's always going to be significantly less efficient
to get them from the application.
Yes, LDAP i
