Christopher Cobb wrote:
>
> I am hitting a wall trying to implement my desired login architecture.
>
> [...]
> Now the problem. If I try to use forward() to get to /path/to/ProtectedPage.html,
> it fails because static .html pages are not supported by forward.
I'm afraid this may depend on how the servlet engine developer has interpreted
the specification and whether the engine is an integrated part of the web server
or an add-on engine.
Web servers with a built-in servlet engine (e.g. JWS and our LWS), usually use
a file servlet to handle requests for static files like HTML and images. A
call like getRequestDispatcher("/foo.html") goes through the normal
path-to-servlet mapping and an RD for the file servlet is returned. So in this
case it works fine.
Add-ons on the other had are usually set up to only handle servlet requests
and don't have a corresponding file servlet to serve static files; the web
server takes care of static files without involving the servlet engine.
So here a call to getRequestDispatcher("/foo.html") typically returns null.
Even an add-on can of course include a file servlet to handle exactly this
situation, but then it (may) bypass the web server's ACL controls. It could
also handle this situation with a special RD that uses a URLConnection back
to the web server, but again this may compromise security since the request
to the web server now comes from the servlet engine instead of the real user.
Is this security problem a big deal? Well for some it probably is but as
long as a servlet can open a file directly using a File object and a path
returned from SerlvetContext.getRealPath(), including a file servlet in
an add-on engine doesn't compromise security more than it already is.
So asking add-on engine vendors to do this may be the easiest way to get
consistent behavior.
As you can see it's a tricky situation. I would love to hear what others
feel about this.
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
