tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Getting host name inside tomcat realm implementation
Date Wed, 25 Jun 2014 14:48:44 GMT
Hash: SHA256


On 6/25/14, 10:39 AM, Mark Thomas wrote:
> On 25/06/2014 15:35, Christopher Schultz wrote:
>> Konstantin,
>> On 6/25/14, 5:23 AM, Konstantin Kolinko wrote:
>>> 2014-06-24 21:09 GMT+04:00 Neeraj Sinha 
>>> <>:
>>>> I am using form based authentication (tomcat 7.0.34) and I 
>>>> have the implementation of custom realm class which extends 
>>>> RealmBase class. Inside the getPrincipal() method 
>>>> implementation, I am calling backend service to save some
>>>> login details. I need to pass host name to backend (I have 2 
>>>> applications running under different hosts connected to same 
>>>> DB, so to know the login source of user). Hosts are
>>>> configured in server.xml.
>>>> Any help/links/URL much appreciated.
>>> A Realm is just a DAO class used by Authenticator valves. The 
>>> idea is that a Realm can be shared between web applications
>>> (by placing it at the Host or Engine level). If you want access
>>> to the request, you should implement an Authenticator.
>>> There have been some discussions on changing APIs of 
>>> Authenticators and Realms to be more friendly for extension,
>>> but nobody came up with a specific idea.
>> I have some code laying around for extending RealmBase to allow 
>> changes to the password-derivation algorithm, but it wouldn't 
>> change the public API of the Realm class in a way that wasn't 
>> backward-compatible.
>> Changing Realm to include additional information (i.e. the 
>> request) would break that API. I can't imagine we'd change that
>> API for Tomcat 7 and it's getting pretty late for Tomcat 8 (8.0.9
>> was just voted "stable").
> See the release notes for which APIs may change and how. For Realm,
> we can add new methods and deprecate existing ones but we can't
> change or remove existing methods.


For the same of argument, let's say that we add a new method:

  public boolean authenticate(String username, String password,
HttpServletRequest request)

Since it's not abstract, it's backward-compatible, at least from a
build and runtime perspective (e.g. no NoSuchMethodError will occur).

However, if we add that method, it makes sense that we might use it.
And if a client has overridden authenticate(String username,String
password) then their method doesn't get called anymore.

Adding a method like setRequest(HttpServletRequest) would be
reasonable, except that Realm objects are shared and expected to be
threadsafe, so that's not going to work.

For securityfilter, what "we" implemented (before my involvement) was
a second interface (with a method that includes HttpServletRequest)
that could be optionally implemented. If the second interface was
implemented by the Realm, then the alternative method was invoked. If
the optional interface was not implemented, then we called the "old"

The above is really the only good way I can think of off the top of my
head to provide extra information to the Realm in a completely
backward-compatible way.

A bad way I can think of would be to provide the extra information as
a thread local variable that the Realm implementation can sniff. I
feel like using threadlocal in this way is simply a lazy way to avoid
passing objects in the traditional way (i.e. on the stack).

There is also the complexity introduced by the fact that there are
different authenticate() methods for every type of authentication
(basic/form, digest, and SSL). That means that we basically need 4
flavors of the same method(s) with extra data being passed-into the

- -chris
Version: GnuPG v1
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message