----- Original Message -----
From: "Doug Black" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
