Hey I love that! Thanks, let me try it!

Now, with this solution, I figure i can't fore stuff that doesn't match
the "to be secured" pattern to go over http and not https if it is
requested, right? I still can live with that, but it would sure be
cool..

Thanks!

On Mon, 2002-12-02 at 19:31, Craig R. McClanahan wrote:
> 
> 
> On 2 Dec 2002, Alexander Wallace wrote:
> 
> > Date: 02 Dec 2002 18:41:26 -0600
> > From: Alexander Wallace <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > To: Tomcat Users List <[EMAIL PROTECTED]>
> > Subject: Filters don't affect request dispatcher forward
> >
> > Hi there. I wrote a filter to ensure that resources that i want accessed
> > using https are, and the ones that don't need to aren't.
> >
> > I found out that filters are only applied if the request came from the
> > user, by typing the url or using a link, etc. They are not used if the
> > resource is called using request dispatcher.
> >
> > Supposedly this is becouse of a lack of specifications in the servlet
> > api, but that should be fixed in the api used by tomcat 5.
> >
> > Is all this correct?
> 
> Yes, basically.
> 
> > Is there a work around while tomcat 5 is released?
> 
> You can use a security constraint with a <transport-guarantee> element to
> require that certain accesses be performed only on SSL connections.  Then,
> the container will do the necessary redirect for you.
> 
> An example that requires any (context-relative) path starting with "/foo"
> or "/bar" to be done on SSL would look like this:
> 
>   <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>SSL-Only Portion Of This Webapp</web-resource-name>
>       <!-- Specify as many patterns as you need here -->
>       <url-pattern>/foo/*</url-pattern>
>       <url-pattern>/bar/*</url-pattern>
>     </web-resource-collection>
>     <user-data-constraint>
>       <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>     </user-data-constraint>
>   </security-constraint>
> 
> Note that, because there is no <auth-constraint>, login will not be
> required -- only execution over SSL will be required, and only for URLs in
> the named "subdirectories".  All other accesses to the webapp will be
> allowed over either SSL or non-SSL requests.
> 
> >
> > Also, does someone have or knows of a proven filter that redirects to
> > http or https? Mine seesm to work ok, but i want to make sure I'm not
> > missing something.
> >
> 
> With the above security constraint, you won't need a filter at all :-).
> 
> > Thanks in advance!
> >
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to