David Bullock wrote:

> Thanks Tim for your reply.  Problem not solved yet, but perhaps you have some more
> ideas....
>
> Tim Stephenson wrote:
>
> > At whatever point in time this is established place it in the session object.
> > Then at the top of every page extract and test this flag. If true continue page
> > execution, else redirect to logon page.
>
> This is the very point where I run into trouble  Not every page I wish to protect
> *is* a servlet which can perform such a test.   Some resources will be just dumb
> files.  I was trying to avoid my CatchEverythingAndForwardItIfOkServlet having to
> evaluate whether it was a servlet resource requested, or just a plain file.  I
> want to delegate this responsibility to the servlet container, as the
> RequestDispatcher interface allows for.
>
> My problem is, if I use RequestDispatcher, then my Servlet at '/' might forward to
> a file at '/login.html' (or anywhere else) but the servlet itself will again get
> invoked ... again and again and again.
>

How about making your default servlet (mapped to "/") a little smarter.  If it knows
the requested resource is a static file, it can just serve that file directly,
instead of doing a RequestDispatcher.forward().  Only forward for the cases where you
know that the resource will be handled by a servlet (or a JSP page) -- Because of the
way mapping rules work, the "/" match back to your default servlet only occurs if the
path is not matched by some other mapping rule.

If you could tell static resources from non-static resources by something like
filename extension, a variation of this would be to create a simple file-serving
servlet (say, copying the code from Tomcat's implementation) and add whatever
protection code you need.  Then, create a servlet definition for this servlet that is
mapped to a filename extension like "*.html".  Now, any request for "index.html" or
"menu.html" in your app goes to this servlet instead of the default one.  You could
extend this to any number of extensions by creating multiple servlet definitions for
the same servlet class, each mapping a different extension.

>
> Indeed, it would seem that any Servlet using RequestDispatcher could not be mapped
> to any URL without causing this self-referential/recursion issue.  But I don't
> think the Servlet API designers (both 'official' and 'community') would let a
> 'gotcha' like that slip through, being the intelligent people they are.
>
> So I'm presuming there's some aspect of the API that I haven't understood properly
> (and I *have* read the Servlet 2.2 spec).
>

The key rule is that the "longest match wins" (Section 10.1, rule #2).  If you have
any servlet mapped to a URI, or the proper prefix of a URI, or a filename extension
pattern that matches the URI, that mapping will take precedence over the default
servlet mapped to "/".

> David Bullock

Craig McClanahan

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to