-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 2/21/13 6:31 AM, André Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> André,
>>
>> On 2/20/13 4:20 PM, André Warnier wrote:
>>> In relation to a couple of recent posts, I have a naive
>>> question :
>>>
>>> In a servlet, to retrieve the authenticated user-id (if any),
>>> I use
>>>
>>> String userName = request.getRemoteUser();
>>>
>>> Now, suppose I wanted to create a servlet filter which (under
>>> certain conditions), would force the current request to be
>>> authenticated as user "someuser", how would I do that ?
>>>
>>> I s'pose it would too much to ask that it would just be
>>>
>>> request.setRemoteUser("someuser");
>>
>> As long as you only want to "trick" some filter or servlet
>> further-down from your own, you can install a filter that:
>>
>> 1. Wraps the request with an HttpServletRequestWrapper which...
>> 2. overrides getRemoteUser() to return whatever you want it to
>> return.
>>
>> If you have to pull the wool over the eyes of a Valve, you'll
>> have to write a Valve and install it at a suitably-early in the
>> pipeline.
>>
> Well,
>
> Mark Thomas wrote:
>>
>> Almost, but you need to use a method that actually exists in the
>> API.
>>
>> HttpServletRequest.login(String username, String password)
>
> So it does not appear so easy after all.
>
> To Mark : why "password" ? To Chris : why is that so complicated ?
Are you saying that writing a filter is complicated? It's not so bad...
If you want to /actually/ authenticate a user, you could write a
Filter that simply calls login(). However, if you want to only
masquerade as an authenticated user, I think you have to wrap the
request as described.
You have to do the whole Valve thing if you need to trick /Tomcat/
into thinking that a user has been authenticated when really it hasn't
happened because Tomcat implements container-managed authentication
and authorization using a Valve -- and all Valves run before all
Filters run. Thus, you have to install your fake-auth Valve before
Tomcat's auth valve runs -- because *that* is the Valve that you have
to trick.
> In my idea, this thing consisted simply in "stuffing" a user-id in
> the userPrincipal object associated to the current request. I
> don't really need a password, do I ? I do not really want this to
> run again through any real authentication mechanism; I know that
> whetever user-id I put in there is "valid enough". I know that the
> Request itself is not modifiable, but the place where the
> associated user-id is stored is not directly in the Request, or is
> it ?
Yes and no: Tomcat does whatever it wants internally. The only way to
do what you want in a container-agnostic way is to wrap the request
and change the behavior of getUserPrincipal: that's just how things
are done in servlet-spec-land.
> The idea is for example (as in a recent post to the list) : the
> servlet filter checks that the request is coming from the internal
> network. If so, we can just set the user-id to "internal" and let
> it through. Otherwise, we return a 401 or a login page e.g.
Yup, it's that simple but it can get hairy if you have to trick Tomcat
into thinking that the user is authentication when he really isn't.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEmdocACgkQ9CaO5/Lv0PAorACggjMR1bOTwQqkVM1tsJbxWfEY
LscAoKk9qjJH7hb7ljtWJaTyJHMPbWq2
=FSaa
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
