Getting additional attributes for logged on users
Hi there, from a servlet, the logged on user is represented by a Principal instance, which has a getName() to get the logon name of that user. In most cases, that is a more or less cryptic name like c.klein or m.scott. Some of our customers like the name of the currently logged on user be displayed in the application's GUI. We all know that from many popular applications. While relying on the Servlet specs only, we can just show that non-user-friendly logon name. Our customers prefer seeing the user's display name. Other attributes of the user, like e-mail address, phone number, department etc., is often welcome (if not required) information during an application's lifetime. It's not too hard to hook into session initialization and get the required extra information, for example through JDBC or JNDI, if the user database is actually an Active Directory Server. That information can then be stored in the user's session attributes map. However, one has to implement that information retrieval "by hand" for every application and/or customer. Even worse, typically credentials are required to access the storage in which that information lives. If it's in the application's 'standard' database, there's a good chance to have a Tomcat connection pool. However, in general, you need credentials and access data to get these additional attributes (credentials and JDBC URL may be configured in Context or Servlet parameters). Does anybody know a more general way to get such extra user attributes? My proposal: Typically, those desired extra attributes are stored in the user's record in the user database. That may be a SQL database or may be an Active Directory Server (or any other directory), which is already used for authentication and authorization. Wouldn't it be cool to make the Realm get us that extra information? Why the realm? First, in order to perform authentication, the Realm already has access to the user database. So, access data and credentials must not be configured twice at different places. Second, the Realm knows how to query the user database and does that already for retrieving roles and passwords. Getting some more fields shouldn't be a big deal. Third, the Realm actually creates and initializes the Principal instance so, it should be easy to store these extra user attributes in an extended version of the TomcatPrincipal class. A simple MapString> should be sufficient, but for the sake of uniformity, the well known methods getAttribute, getAttributeNames, removeAttribute and setAttribute may be a better option. That's clearly something not all Realms can/shall support. Likely JAASRealm will not, since it uses custom Principal classes. But JNDIRealm, JDBCRealm and DataSourceRealm (not yet sure about UserDatabaseRealm) could easily support that feature. In its simplest form, these Realms get a new configuration property 'extraAttributes', which takes a comma separated list of field names to retrieve. Implicitly, for an SQL-based Realm, these fields are queried from the 'userTable' table. The JNDIRealm tries to find these attributes from the user's entry in the directory, of course. More complex configurations are possible (but likely not needed). I'm curious what you think about it :) Carsten - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] caching DB items in startup listener
Hi, What happens when the DB has problems when the webapp starts? Will the startup fail then? I think doing lazy init is the better approach, when db comes back it will work again after the webapp did start. Mfg Thomas Am 8. April 2021 13:54:46 MESZ schrieb "Berneburg, Cris J. - US" : >Hi Folks > >I'm working on an old legacy app and noticed something. It caches a >bunch of info (lookup table data) from the database using a >ServletContextListener. I think opening DB connections in a listener >is reasonable. While there is no business logic in the listener, I'm >not sure doing a bunch of DB heavy-lifting operations in a context >listener is a "good thing", although I don't really have a concrete >reason why. Perhaps I'm just being fussy. > >Anyway, in your opinion: > >1. Is performing DB heavy-lifting operations in ServletContextListener >a "reasonable" practice? >2. Is there a "better" way of caching said items at application >startup? > >Thanks for your time and consideration. :-) > >-- >Cris Berneburg >CACI Senior Software Engineer > > > > >This electronic message contains information from CACI International >Inc or subsidiary companies, which may be company sensitive, >proprietary, privileged or otherwise protected from disclosure. The >information is intended to be used solely by the recipient(s) named >above. If you are not an intended recipient, be aware that any review, >disclosure, copying, distribution or use of this transmission or its >contents is prohibited. If you have received this transmission in >error, please notify the sender immediately. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Setting a Request Attribute from a custom Realm
Tim, On 4/8/21 09:11, Tim K wrote: On Wed, Apr 7, 2021, 3:43 PM Christopher Schultz < ch...@christopherschultz.net> wrote: You can't, using the existing API. You might be able to do it with some nasty ThreadLocal solution, but I think you are stuck without resorting to legerdemain. -chris Would it be possible to implement a new feature to the existing realm API so it can accommodate messages passed back to the front end? I have some sketches of something like this literally on paper somewhere around here to create an interface for applications subscribe to authentication events. It would, for example, allow you to write a "failed login" record to your database that includes not only the user's username who failed, but also their IP address (which comes from the request, of course. Would that kind of thing help in your use-case? For example, when using the LockoutRealm, is there from the front-end to alert the user that they are actually locked out? No, it doesn't do that. You simply get an authentication failure. Something I hadn't considered was the potential flexibility of the JASPIC authenticator, which may be able to do stuff like this. I have never dived-into how all that works. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] caching DB items in startup listener
Cris, On 4/8/21 07:54, Berneburg, Cris J. - US wrote: Hi Folks I'm working on an old legacy app and noticed something. It caches a bunch of info (lookup table data) from the database using a ServletContextListener. I think opening DB connections in a listener is reasonable. While there is no business logic in the listener, I'm not sure doing a bunch of DB heavy-lifting operations in a context listener is a "good thing", although I don't really have a concrete reason why. Perhaps I'm just being fussy. Anyway, in your opinion: 1. Is performing DB heavy-lifting operations in ServletContextListener a "reasonable" practice? 2. Is there a "better" way of caching said items at application startup? Thanks for your time and consideration. :-) IMHO there is no better way than using a ServletContextListener to load things at startup. Your only other spec-compliant option is to use a Servlet with load-on-startup set and do your work in the init() method, which is ... ugly. SCL is the way to go, here. Another option would be to perform "lazy loading" instead of a-priori loading of this data. You will take the hit of loading the data when it is first requested, which may negatively impact user experience. It might also mean that you have to be more careful about cross-thread synchronization, etc. since you can't guarantee that the work has already been done before a client tried to access the cache. If you are concerned about startup times, lazy-loading is a good solution. It can also improve your memory usage if that data is never actually needed. We have a primary application at $work where we need to have a lot of information in mrmoey to be able to do important stuff. This information evolves over time and has a long (essentially infinite) history. We can never really get rid of anything entirely, but the older some of that data gets, the less likely it is to be used. We loaded 100% of it every time at startup. At some point, it started taking several seconds to launch the application, then eventually several tens of seconds and I decided it wasn't tolerable anymore. So I switched to loading things on-demand and it made not only a significant performance improvement on startup (hey! we are loading nothing on startup now! super fast!), it significantly reduced the memory footprint of the in-memory cache of data because that rarely-used older stuff was just never being loaded at all. To be sure, it was a significant change to our application, but one well worth the investment. (We also have a user-initiatable process to "reload" the data that was taking the same amount of time. Not it just empties the cache and does nothing else. More faster. :) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting a Request Attribute from a custom Realm
On Wed, Apr 7, 2021, 3:43 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > You can't, using the existing API. > > You might be able to do it with some nasty ThreadLocal solution, but I > think you are stuck without resorting to legerdemain. > > -chris Would it be possible to implement a new feature to the existing realm API so it can accommodate messages passed back to the front end? For example, when using the LockoutRealm, is there from the front-end to alert the user that they are actually locked out? - Tim
[OT?] caching DB items in startup listener
Hi Folks I'm working on an old legacy app and noticed something. It caches a bunch of info (lookup table data) from the database using a ServletContextListener. I think opening DB connections in a listener is reasonable. While there is no business logic in the listener, I'm not sure doing a bunch of DB heavy-lifting operations in a context listener is a "good thing", although I don't really have a concrete reason why. Perhaps I'm just being fussy. Anyway, in your opinion: 1. Is performing DB heavy-lifting operations in ServletContextListener a "reasonable" practice? 2. Is there a "better" way of caching said items at application startup? Thanks for your time and consideration. :-) -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: Tomcat 9.0
Hi, On Thu, Apr 8, 2021 at 3:25 AM Mohamed Eliyas Abdul Kadar < mohamed.ka...@neogenomics.com> wrote: > Hi All > I am planning to use Tomcat for my development server. Initially we > planned to go with version Tomcat 9.0.41. Now I see newer versions are > release on top of that and see the latest version is Tomcat 9.0.45. Please > let me know if there is any major fix of Tomcat 9.0.41 made on higher > versions or we are good with Tomcat 9.0.44 as Tomcat 9.0.45 is not having > any release date. > Please consult with https://tomcat.apache.org/tomcat-9.0-doc/changelog.html for the changes in each version. Martin > > Regards > Eliyas > This communication and its attachments contain confidential information > and is intended only for the named addressee. If you are not the named > addressee you should not disseminate, distribute or copy this > communication. Please notify the sender immediately if you have received > this communication by mistake and delete or destroy this communication. > Communications cannot be guaranteed to be secured or error-free as > information could be intercepted, corrupted, lost, destroyed, arrive late > or incomplete, or contain viruses. The sender therefore does not accept > liability for any errors or omissions in the contents of this communication > which arise as a result of transmission. If verification is required please > request a hard-copy version. NeoGenomics Laboratories, 12701 Commonwealth > Dr, Fort Myers, FL 33913, http://www.neogenomics.com (2021) >
Re: [OT] programming style or mental process ?
Guten Morgen Peter :) Guten Morgen Carsten and All [...] I may add, that a French Café au lait (pronounced Olé, which is not French :-O ) is also an option. Maybe my German coffee expertise is kind of narrow and shaped by personal experience (having my coffee w/o milk)... OLE? Isn't it something used in Windows programming? *lol* Obviously, coding and coffee are very closely related... Carsten - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] programming style or mental process ?
Guten Morgen Carsten and All
> Am 08.04.2021 um 07:20 schrieb Carsten Klein :
>
>
>> (And dutch people. Where are they in this discussion by the way ? (but they
>> have only one type of coffee I think)).
>
> Dutch people may only have one type of coffee (actually I don't know). But
> remember, Dutch people have 'Coffee Shops' offering stuff far beyond
> coffee... :) Is there a relation between that and usage of Yoda style?
>
> Germans used to drink so called 'filter coffee' for decades, which today,
> even if served hot, many people would call 'cold coffee' ('kalter Kaffee' in
> German), an idiom that could be translated to English as 'an old hat').
>
> Now, thanks to companies like De'Longhi or Seaco (which is now owned by
> Philips and so is actually Dutch), most of us prefer Italian coffee types
> like Espresso, Cappuccino or Latte Macchiato.
>
>
I may add, that a French Café au lait (pronounced Olé, which is not French :-O
) is also an option.
Peter
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
