I have read dozens of emails similar to the message below and find this
response to be excellent. I have similarly run into the same problem and am
wondering if ServletExec has any plans to implement a FileServlet - or
other solutions for this issue.
>Christopher Cobb wrote:
>>I am hitting a wall trying to implement my desired login architecture.
>What I want is this. A user wants to get to ProtectedPage.html, but I want
>to interpose a login-checking servlet, >which forces the user to login if
>necessary, then sends them to the desired page after successfully login in.
>>
>> [...]
>> 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".
--
Jason Puyleart
Internet Concepts, LLC
[EMAIL PROTECTED]
Office: 608.285.6600
Fax: 608.285.6601
___________________________________________________________________________
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
