tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: how to write a valve
Date Mon, 17 Oct 2016 15:53:13 GMT
On 17.10.2016 16:57, Christopher Schultz wrote:
> Hash: SHA256
> Mark,
> On 10/14/16 6:08 AM, Mark Thomas wrote:
>> On 14/10/2016 10:51, André Warnier (tomcat) wrote:
>>> On 14.10.2016 10:05, Mark Thomas wrote:
>>>> On 13/10/2016 16:04, Campbell, Lance wrote:
>>>>> Tomcat 8.0.38
>>>>> In my Eclipse development environment when particular
>>>>> servlet requests are made I want to simulate going through
>>>>> Shibboleth prior to Tomcat handling the request.  I wanted to
>>>>> see if this will work.
>>>>> In Eclipse within each dynamic web application I would add a
>>>>> valve to the context.xml file.
>>>>> The valve would:
>>>>> 1)      Check the URL request.
>>>>> 2)      If the URL string matches a list then it will add
>>>>> particular name value pairs to the request.
>>>>> Example of a possible valve:
>>>>> <Valve className="my.valves.ShibbolethSimulationValve" />
>>>>> 1)      Can a valve actually identify a particular URL path?
>>>> Yes. Valves have access to Tomcat's internal request and
>>>> response objects.
>>>>> 2)      Can a valve add an attribute to the request prior to
>>>>> the servlet getting the request?
>>>> Yes.
>>> Apologies for barging in.  Does that mean that, at this point,
>>> the request is still "mutable" ? (at the servlet filter level, it
>>> isn't, as far as I know).
>> Mostly, yes since a Valve has direct access to the internals.
>> In a Filter you are limited to what you can do with
>> HttpServletRequest. It isn't completely immutable (setAttribute(),
>> setCharacterEncoding(), changeSessionId()) but you have a lot less
>> scope for changing the request.
> In both cases (Filter, Valve), it's possible to wrap the request
> object (HttpServletRequest in the case of a Filter, (Tomcat) Request
> in the case of a Valve) and basically change anything you want. There
> are certainly things you can't do and expect everything to work -- for
> example, disconnecting the input streams, etc. but many things are
> possible including intercepting calls to the request methods, which is
> of course the most interesting thing that you can do in general.

In this case, the OP originally mentioned "add an attribute to the request".
I have the feeling that the word "attribute" here was not very specific, and in reality 
(since we are talking about an authentication method "faking" another one) it may have 
meant "add a HTTP header" (the OP is welcome to correct if I am mistaken).
Assuming that you were in a Filter, what you would need to do in such a "wrapper", would 
probably be to
1) copy the existing request headers in your own, wrapper-specific, new, headers collection
2) add the additional header to that copied collection
3) override all the methods by which one can obtain these headers, to return the 
copied/modified version instead of the original headers collection (or member of)

But maybe in a Valve, you do not need to go through all of that, and you can modify the 
original headers collection directly. (question mark)

> Tomcat does not include wrapper classes for its Request and Response
> objects, but there are examples includes in a long-standing Bugzilla
> issue[1] that anyone is welcome to use.
> In general, I would say that anything that *can* be done in a Filter
> *should* be done in a Filter (as opposed to a Valve). In the OP's
> case, it might not be entirely possible if his operation needs to
> affect the way that authentication is done, since that is typically
> done (for container-based authentication) in Valves before any Filter
> is called.
> - -chris
> [1]

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

View raw message