tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Getting host name inside tomcat realm implementation
Date Wed, 25 Jun 2014 14:48:44 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

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 
>>> <neerajsinha.dac@gmail.com>:
>>>> 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.

Understood.

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"
method.

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
method.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTquFMAAoJEBzwKT+lPKRYp+8P/RqN5Dhs31ijnLCqIl5rfPK+
UAgtUueapxSU2yMGHC8u9Lh95uhfWhnHXMo+3LDNDlgM/mF0K0Otad9wNot2BN+C
8wCqvkthHkX6nOVulDghnCtmlBTOVDcdQbzuzJxxeitEwfho/iQnZsFfB4xZN5ID
sK13CYSVjWB+eSz7esLNGX6SfG6QK1UWktaVlgbvHho9ezCDNo45Elg5+xVAYsBl
snPgqDgeIypBBuRe6EcUB8wxy5/Mfqq7hwQBWb1mGYq7Plu3vvtyP4Ng2G1jp5tk
awhlE86FhSHlNhW6s2l2dVs3JCNcn6albMvr04kxGaKMoMQGkHWLSk+D+vF/JDHX
mwn4NKb7gfzOqcDaNeOOe8yqEhAeSKIBpzvQKL9yjW3kmKFcuH9ihp9ETZbXM8IQ
+ejyEH/JP8NcdhgjKSW6rVKhq1eQhSAnjahQbFg2C6yL0pGbR35wlrAE+xR0eb2x
nG2ombckvsopBtbAS0SnKnybSk+kDvFujpeWYL6F4cPBYcRCZLYa9bWe77ewVmXk
FJZg98g5Vu+E8qDFs32zUlAsQShlxFX+1CIhi+riUx06IeahVAxLwZlo61nbAn3K
8TmvtK/eKle76XoF+2aI0nHLUiuAsGJZaQ39svPs2TEFK0L3MRJVhBLp+b8u5qGo
2yKirH7okrznvxWajst6
=9iw2
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message