--

Hi Don,

I'm interested in your solution. I've developped a similar servlet to 
access private html pages. I don't have a lot of html pages in the 
private area and performance is not really a problem for me. 

What I've done is the following:

-I've used mod_rewrite to redirect all requests on /private to my servlet
-I check the client authentification in the servlet
-If he's authorized to access the private area then I directly serve
 the html page within the servlet (open the html file, copy the content
 in the response stream).
-If he's not autorized, I redirect the request to an error page.

I've also implemented a simple cache mechanism to avoid to reload the file
each time it's requested.

In fact my solution is based on the one which is used for the JDC web site.
Have a look at the following URL for more details:
http://developer.java.sun.com/developer/technicalArticles/InnerWorkings/BackstageSession/index.html#hardware

Regards,
Benoit

Don Garrett wrote:
> 
> --
> 
>   Ok, this is almost a mod_rewrite question, but not quite. I think that
> I have a solution that works, but has some potential problems. I'd like
> to see if there are anyone sees a better solution.
> 
>   I picture an authentication scheme that works like this:
> 
> A servlet is configured to be /private
> 
> Actual content is stored and servered from /private_auth
> 
>   When a user request comes in for /private/index.html the servlet
> performs authentication. If the request passes, it redirects the request
> to /private_auth/getPathInfo().
> 
>   A mod_rewrite rule is in place that tests the HTTP_FORWARDED value
> and/or the HTTP_REFERRED for accesses to /private_auth to see if the
> request was redirected here from the applet. If so, it passes through
> unchanged. If not, it's rewritten to some error handling page/servlet.
>
> Problem one:
>   What is the base href used by browsers in this case? /private, or
> /private_auth? If it's /private_auth, then relative links will try to
> bypass the servlet and fail to get through (I hope).
> 
>   This could be fixed by having MOD_REWRITE direct requests that fail
> it's tests back to /private, but then browsers that don't give out
> REFERRED/FORWARDED are potentially stuck in an infinite loop.
> 
> Problem two:
>   Browsers which don't support HTTP_REFERRED and HTTP_FORWARDED are left
> out. This is a problem for unusual configurations (Palm Pilot browsers,
> etc), or browsers going through a brain dead proxy.
> 
> Problem three:
>   Authentication is based on information supplied by the client
> (HTTP_FORWARDED or HTTP_REFERRED), this information could be cooked up
> by a hacker to bypass the security. They would have to be knowledgable
> and motivated, but it's possible. For most cases, this is not an issue,
> but if the hole can be closed, I'd sleep better at night.
> 
> --
> Don Garrett                                          [EMAIL PROTECTED]
> BGB Consulting                  http://www.bgb-consulting.com/garrett
> 
> --
> --------------------------------------------------------------
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]
> READ THE FAQ!!!!     <http://java.apache.org/faq/>
> Archives and Other:  <http://java.apache.org/main/mail.html/>
> Problems?:           [EMAIL PROTECTED]

-- 
Benoit Foucher


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
READ THE FAQ!!!!     <http://java.apache.org/faq/>
Archives and Other:  <http://java.apache.org/main/mail.html/>
Problems?:           [EMAIL PROTECTED]

Reply via email to