tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject Re: Write custom valve?
Date Thu, 26 Jul 2007 06:13:04 GMT

----- Original Message ----- 
From: "Doug Black" <doug@westrockvisions.com>
To: <users@tomcat.apache.org>
Sent: Wednesday, July 25, 2007 9:58 PM
Subject: Re: Write custom valve?


> Filip Hanik - Dev Lists <devlists <at> hanik.com> writes:
>
>> take the source code of the RemoteAddrValve and start there.
>> Basically, in the valve is request.getPrincipal returns null, then
>> redirect them to a URL that is protected by your web.xml and requires a
>> login.
>>
>> remember to not trigger the valve on the "protected" urls
>
> Johnny Kewl <john <at> kewlstuff.co.za> writes:
>
>>
>> Doug, I have never tried this, so as usual, I guessing here.
>>
>> I dont think you are going to come right with the standard valves, nor do
>> I
>> think you should try make a custom valve.
>> Rather look at filters, they not much more difficult to make than a
>> normal
>> servlet, and you will find tons of stuff on the web, maybe the very thing
>> you looking for.
>> If you use netbeans, there is a standard project wizard that will get you
>> going with a filter.
>>
>> The concept is interesting, and I'm thinking that you cant really protect
>> the web pages with standard security, because if you do, I think that
>> will
>> kick in even before the filter gets a chance to look at it. Maybe other
>> guys
>> can think of another way, but I think that the pages will have to be
>> protected by the filter, not by standard Web.xml configuration.
>>
>> So... luv this guessing stuff ;).... I think you effectively have to make
>> one web page as your realm log on page, only this page you protect with
>> the
>> standard realm web.xml stuff.  The rest are unprotected. Then your filter
>> logic is something like this....
>>
>> If the IP or Host name is allowed.... let it through
>> If its not allowed.... check the username because if the user is
>> authenticated, there will be one.... if username let it through.... else
>> if
>> user name is null, redirect to logon page.
>>
>> Filters are a really nice things to learn, and I dont think its too
>> difficult.... but I just wanted to warn you, that the filter will not be
>> able to intercept realm security, rather it has to take over that
>> function.
>> So if the access is simple.... like if they can get into that login page,
>> then they can go anywhere.... its easy, but if you have a site where some
>> people can go some places and not others, then you going to find yourself
>> rebuilding tomcats realm security roles... a lot of work... or doing
>> something like setting a session variable that a pages has to check....
>> ie
>> A,B and C users are allowed in here... ie if you need to filter pages on
>> roles, the fun really starts.
>>
>> So think about it, because I think the devil is in the details, and in
>> the
>> end it may be easier to just make everyone log on.
>>
>> From a philosophical point of view... I dont think one should use ip
>> filters
>> to allow access... its not good security. So if you have a lazy boss that
>> doesn't want to type in a password, and his IP must go thru, tell him
>> he's a
>> security risk, on the other hand if its a customer that wants that, with
>> a
>> big wallet... its probably ok;)
>> I think everyone should log on, and that getting too far away from the
>> standard security could get very tricky.... I think those valves are more
>> intended to simply ban people that have become a pain in the behind,
>> never
>> to let the privileged through.
>>
>> Have fun....
>>
>> From: "Doug Black" <doug <at> westrockvisions.com>
>>
>> > How can I best pass ips allowed by a valve to pass through to my
>> > application
>> > while forcing ips that are denied to log in through a realm? The only
>> > possible
>> > behavior I can detect of either RemoteAddrValve or RemoteHostValve is
>> > to
>> > force
>> > requests through the IP or host filter and also through the user realm
>> > for
>> > the
>> > context. Do I have to write a custom valve java class? How hard is this
>> > for an
>> > intermediate Java writer? Any tips on how to do this?
>> >
>> > I apologize that I submitted essentially the same question a couple
>> > days
>> > ago,
>> > but I got no responses so I thought I'd try with a less verbose
>> > phrasing.
>> >
>> > Thanks, Doug
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To start a new topic, e-mail: users <at> tomcat.apache.org
>> > To unsubscribe, e-mail: users-unsubscribe <at> tomcat.apache.org
>> > For additional commands, e-mail: users-help <at> tomcat.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users <at> tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe <at> tomcat.apache.org
>> For additional commands, e-mail: users-help <at> tomcat.apache.org
>>
>>
>
> Thanks Fillip and Johnny. First two follow up questions and then some
> description of my plans and responses to some of Johnny's philosophical
> points.
>
> If I understand both Fillip and Johnny correctly, 1) with the custom valve
> approach I'm going to need three contexts but 2) with the jsp filter
> approach I
> will need only one context but I can not use any Tomcat basic security
> checking
> on that context (with the caveat that I can have checking of known
> violators,
> spoofers, etc. at the context level if I don't already have it at the host
> engine or still higher levels). Is this dichotomy right?
>
> With the filter approach my logic would be as Johnny laid out:
>
>> If the IP or Host name is allowed.... let it through
>> If its not allowed.... check the username because if the user is
>> authenticated, there will be one.... if username let it through.... else
>> if
>> user name is null, redirect to logon page.
>
> But with the valve approach I  would need a logic as below:
>
> User urls to -> context A -> Check IPs with Valve ->
>   If request.Principal is null ->
>     redirect -> Context B -> check user authentication
>     If login Ok ->
>      redirect -> Context C (application context)
>   Else redirect -> Context C (application context)
>
> Second question, if my valve logic is right, how do I insure that Context
> C can
> only be reached by redirects from one of the other two contexts?
>
> END of questions. Rest of reply is background info:
>
> I will evaluate both approaches, writing a custom valve and using a
> filter. On
> the valve side, starting with the source code for RemoteAddrValve is what
> I was
> thinking, but its important for me to get this confirmed by someone else
> and its
> really important to now know that the crux is with request.getPrincipal.
> On the
> surface, using a custom valve sounds easy but I do fear the complications
> in
> requirements for multiple contexts, as I think I see, and potential
> gotchas in
> messing with basic security, as I think Johnny was guessing. On the filter
> side,
> indeed there is much information on writing jsp filters on the web,
> including
> the first hit in Google search for jsp filters, which was a whole chapter
> from a
> Sun publication on the topic. To my chagrin, I knew nothing about filters
> so
> Johnny's input has been vital. Probably the Tomcat books, etc. say nothing
> about
> them because its a java jsp subject not a Tomcat subject. This looks like
> it is
> the more kosher way to do this, but then I haven't yet found that almost
> already
> complete filter to do what I want, which I might have starting with
> RemoteAddrValve. I do use NetBeans so I will probably start with that
> standard
> wizard that Johnny suggests.
>
> On the philosophical question Johnny raises, Do I really need to do this?,
> the
> answer is yes. My situtation is closer to the deep pocketed customer
> demand then
> to the lazy boss demand. This is a database app that is sold by
> subscriptions to
> institutional, primarily academic, customers. Everybody coming in from an
> IP
> range controlled by a subscribing institution must be allowed in. This
> could
> theoretically be hundreds of thousands of anonymous users. As well there
> are
> some private customers, guest passes, and management logins that could be
> coming
> in from any IP. An example of such a situation is Safari. I am surprised
> this is
> not a more common need and thus surprised that there isn't a built-in way
> to
> handle this in Tomcat (or Apache Webserver?). I guess it comes down to
> question
> of where the division between security and server administration should be
> with
> application development. I can see the argument that sorting out customers
> from
> non-customers shouldn't be an administration/security task but I guess I
> was
> lured by Tomcat literature that touts the virtue of lifting the general ip
> and
> user filtering task from the application developer.
>
> For now, the good news is I don't have provide different access to
> different
> parts of the application, though that might be coming down the road.
>
> Thanks, Doug

Hi Doug, I think Filip and I are talking about the same mechanism, the only
difference is that Filip is answering your direct question, and showing you
how to approach it from, as you asked, the valve perspective, I'm trying to
show you a different way because Valves are
Tomcat specific, and version specific.
My concern is not so much the coding logic, its more that you will find when
you move from 5.5.17, to 5.5.23, to 6.0.13, your valve has to be modified
every time.
Valves dig right into the TC engine, Filters are a standard.... I think
thats a more important consideration. With Valves, you have to study Tomcats
internals, and will get little help else where, with filters, you can buy a
book.

>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


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


Mime
View raw message