You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alexander Wallace <to...@rwsoft-online.com> on 2002/12/03 01:41:26 UTC
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? Is there a work around while tomcat 5 is released?
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.
Thanks in advance!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by Jacob Kjome <ho...@visi.com>.
At 11:50 PM 12/2/2002 -0800, you wrote:
> > 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.
>
>Urm, on my reading of the 2.3 spec, this would be a bug if Tomcat 4.x
>enforces a <transport-guarantee> on a rd.forward/include. Not to mention
>the fact that it would mean that I'd have to go back and spend many more
>hours studying the Catalina API :).
Hi Bill,
My take on what Craig said is to use a Transport Guarantee in replacement
for the filter -> RequestDisplatcher.forward(). So, the Transport
Guarantee would already have taken place. Any forward() happening would
take place place after the transport guarantee did its thing and then the
servlet or filter actually got executed. So, it doesn't seem you need to
study any more than you already are.
Jake
Re: Filters don't affect request dispatcher forward
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 2 Dec 2002, Bill Barker wrote:
> Date: Mon, 2 Dec 2002 23:50:08 -0800
> From: Bill Barker <wb...@wilshire.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Re: Filters don't affect request dispatcher forward
>
>
> "Craig R. McClanahan" <cr...@apache.org> wrote in message
> news:20021202172355.C63095-100000@icarus.apache.org...
> >
> >
> > On 2 Dec 2002, Alexander Wallace wrote:
> >
> > > Date: 02 Dec 2002 18:41:26 -0600
> > > From: Alexander Wallace <to...@rwsoft-online.com>
> > > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > > To: Tomcat Users List <to...@jakarta.apache.org>
> > > 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.
>
> Urm, on my reading of the 2.3 spec, this would be a bug if Tomcat 4.x
> enforces a <transport-guarantee> on a rd.forward/include.
You're correct ... security constraints (including transport guarantees)
are only applied on the initial request. I was offering an alternative to
using a filter for this purpose -- let the container do the work for you.
Not to mention that it's not actually possible to switch to SSL in the
middle of an existing HTTP request *without* doing a redirect ...
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by Bill Barker <wb...@wilshire.com>.
"Craig R. McClanahan" <cr...@apache.org> wrote in message
news:20021202172355.C63095-100000@icarus.apache.org...
>
>
> On 2 Dec 2002, Alexander Wallace wrote:
>
> > Date: 02 Dec 2002 18:41:26 -0600
> > From: Alexander Wallace <to...@rwsoft-online.com>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: Tomcat Users List <to...@jakarta.apache.org>
> > 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.
Urm, on my reading of the 2.3 spec, this would be a bug if Tomcat 4.x
enforces a <transport-guarantee> on a rd.forward/include. Not to mention
the fact that it would mean that I'd have to go back and spend many more
hours studying the Catalina API :).
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by Alexander Wallace <to...@rwsoft-online.com>.
Thanks for the schooling, now it's all clear!
I realy appreciate it.
On Tue, 2002-12-03 at 23:41, Craig R. McClanahan wrote:
>
>
> On 3 Dec 2002, Alexander Wallace wrote:
>
> > Date: 03 Dec 2002 21:42:54 +0100
> > From: Alexander Wallace <to...@rwsoft-online.com>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: Tomcat Users List <to...@jakarta.apache.org>
> > Subject: Re: Filters don't affect request dispatcher forward
> >
> > I have one extra question... Asumming one should not switch from https
> > to http for security reasons... How does one handle the situation in
> > which a user should login with a password (that one would like to
> > encrypt so it can't be sniffed)? Should the whole app be run using
> > https? Isn't that too hard on resources?
> >
>
> If you switch back, you're just as vulnerable as if you did the login
> under non-SSL (in other words, the encryption of the username and
> password on the SSL login gives you a *false* sense of security, not
> anything real). So why bother with all the extra effort in the first
> place?
>
> If you really care about the security of passwords, run the whole session
> in SSL (and buy an extra CPU for your server, for goodness sake, if that
> really matters). If you don't care, life is much simpler if you just run
> everything non-SSL.
>
> If you decide to implement switching back to non-SSL on a public internet
> app, please let me know where it is so I can avoid it.
>
> > Does this not switching from https to http also apply when you have
> > apache handling all the ssl comunication?
> >
>
> Yep ... the issue is the exposure of session id information in cleartext,
> not the mechanics of how you processed it on your server.
>
> >
> > Thanks again in advance.
>
> Craig
>
>
> >
> > On Tue, 2002-12-03 at 18:37, Alexander Wallace wrote:
> > > Ok, thankyou for the advice, I will do that then. What i was trying to
> > > do is actually what you are telling me i shouldn't.
> > >
> > > Again, thanks!
> > >
> > > On Tue, 2002-12-03 at 11:20, Craig R. McClanahan wrote:
> > > >
> > > >
> > > > On 3 Dec 2002, Alexander Wallace wrote:
> > > >
> > > > > Date: 03 Dec 2002 10:21:19 -0600
> > > > > From: Alexander Wallace <to...@rwsoft-online.com>
> > > > > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > > > > To: Tomcat Users List <to...@jakarta.apache.org>
> > > > > Subject: Re: Filters don't affect request dispatcher forward
> > > > >
> > > > > 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..
> > > > >
> > > >
> > > > I'm not sure what you're really asking, but ...
> > > >
> > > > If you declare a security constraint with a transport guarantee, any URL
> > > > that matches the specified pattern(s) can *only* be accessed via SSL. Any
> > > > URL that does not match the pattern can be accessed over *either* SSL or
> > > > non-SSL.
> > > >
> > > > One additional note -- web applications that allow a user to switch from
> > > > SSL back to non-SSL on the same session are broken. What you've just done
> > > > is allowed anyone snooping the network to swipe the session id and
> > > > impersonate your user (for example, click the "buy" button again using the
> > > > credit card number that was entered on a secure page).
> > > >
> > > > You should program your apps that, once a user switches from non-SSL to
> > > > SSL, you never again accept a non-SSL request for that same session id.
> > > > If the user needs to go back (for example, after checking out of an
> > > > ecommerce site you want to buy some more stuff), start a new session first
> > > > (and clear the confidential data you might have captured).
> > > >
> > > > > Thanks!
> > > >
> > > > Craig
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 3 Dec 2002, Alexander Wallace wrote:
> Date: 03 Dec 2002 21:42:54 +0100
> From: Alexander Wallace <to...@rwsoft-online.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Filters don't affect request dispatcher forward
>
> I have one extra question... Asumming one should not switch from https
> to http for security reasons... How does one handle the situation in
> which a user should login with a password (that one would like to
> encrypt so it can't be sniffed)? Should the whole app be run using
> https? Isn't that too hard on resources?
>
If you switch back, you're just as vulnerable as if you did the login
under non-SSL (in other words, the encryption of the username and
password on the SSL login gives you a *false* sense of security, not
anything real). So why bother with all the extra effort in the first
place?
If you really care about the security of passwords, run the whole session
in SSL (and buy an extra CPU for your server, for goodness sake, if that
really matters). If you don't care, life is much simpler if you just run
everything non-SSL.
If you decide to implement switching back to non-SSL on a public internet
app, please let me know where it is so I can avoid it.
> Does this not switching from https to http also apply when you have
> apache handling all the ssl comunication?
>
Yep ... the issue is the exposure of session id information in cleartext,
not the mechanics of how you processed it on your server.
>
> Thanks again in advance.
Craig
>
> On Tue, 2002-12-03 at 18:37, Alexander Wallace wrote:
> > Ok, thankyou for the advice, I will do that then. What i was trying to
> > do is actually what you are telling me i shouldn't.
> >
> > Again, thanks!
> >
> > On Tue, 2002-12-03 at 11:20, Craig R. McClanahan wrote:
> > >
> > >
> > > On 3 Dec 2002, Alexander Wallace wrote:
> > >
> > > > Date: 03 Dec 2002 10:21:19 -0600
> > > > From: Alexander Wallace <to...@rwsoft-online.com>
> > > > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > > > To: Tomcat Users List <to...@jakarta.apache.org>
> > > > Subject: Re: Filters don't affect request dispatcher forward
> > > >
> > > > 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..
> > > >
> > >
> > > I'm not sure what you're really asking, but ...
> > >
> > > If you declare a security constraint with a transport guarantee, any URL
> > > that matches the specified pattern(s) can *only* be accessed via SSL. Any
> > > URL that does not match the pattern can be accessed over *either* SSL or
> > > non-SSL.
> > >
> > > One additional note -- web applications that allow a user to switch from
> > > SSL back to non-SSL on the same session are broken. What you've just done
> > > is allowed anyone snooping the network to swipe the session id and
> > > impersonate your user (for example, click the "buy" button again using the
> > > credit card number that was entered on a secure page).
> > >
> > > You should program your apps that, once a user switches from non-SSL to
> > > SSL, you never again accept a non-SSL request for that same session id.
> > > If the user needs to go back (for example, after checking out of an
> > > ecommerce site you want to buy some more stuff), start a new session first
> > > (and clear the confidential data you might have captured).
> > >
> > > > Thanks!
> > >
> > > Craig
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by Alexander Wallace <to...@rwsoft-online.com>.
I have one extra question... Asumming one should not switch from https
to http for security reasons... How does one handle the situation in
which a user should login with a password (that one would like to
encrypt so it can't be sniffed)? Should the whole app be run using
https? Isn't that too hard on resources?
Does this not switching from https to http also apply when you have
apache handling all the ssl comunication?
Thanks again in advance.
On Tue, 2002-12-03 at 18:37, Alexander Wallace wrote:
> Ok, thankyou for the advice, I will do that then. What i was trying to
> do is actually what you are telling me i shouldn't.
>
> Again, thanks!
>
> On Tue, 2002-12-03 at 11:20, Craig R. McClanahan wrote:
> >
> >
> > On 3 Dec 2002, Alexander Wallace wrote:
> >
> > > Date: 03 Dec 2002 10:21:19 -0600
> > > From: Alexander Wallace <to...@rwsoft-online.com>
> > > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > > To: Tomcat Users List <to...@jakarta.apache.org>
> > > Subject: Re: Filters don't affect request dispatcher forward
> > >
> > > 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..
> > >
> >
> > I'm not sure what you're really asking, but ...
> >
> > If you declare a security constraint with a transport guarantee, any URL
> > that matches the specified pattern(s) can *only* be accessed via SSL. Any
> > URL that does not match the pattern can be accessed over *either* SSL or
> > non-SSL.
> >
> > One additional note -- web applications that allow a user to switch from
> > SSL back to non-SSL on the same session are broken. What you've just done
> > is allowed anyone snooping the network to swipe the session id and
> > impersonate your user (for example, click the "buy" button again using the
> > credit card number that was entered on a secure page).
> >
> > You should program your apps that, once a user switches from non-SSL to
> > SSL, you never again accept a non-SSL request for that same session id.
> > If the user needs to go back (for example, after checking out of an
> > ecommerce site you want to buy some more stuff), start a new session first
> > (and clear the confidential data you might have captured).
> >
> > > Thanks!
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by Alexander Wallace <to...@rwsoft-online.com>.
Ok, thankyou for the advice, I will do that then. What i was trying to
do is actually what you are telling me i shouldn't.
Again, thanks!
On Tue, 2002-12-03 at 11:20, Craig R. McClanahan wrote:
>
>
> On 3 Dec 2002, Alexander Wallace wrote:
>
> > Date: 03 Dec 2002 10:21:19 -0600
> > From: Alexander Wallace <to...@rwsoft-online.com>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: Tomcat Users List <to...@jakarta.apache.org>
> > Subject: Re: Filters don't affect request dispatcher forward
> >
> > 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..
> >
>
> I'm not sure what you're really asking, but ...
>
> If you declare a security constraint with a transport guarantee, any URL
> that matches the specified pattern(s) can *only* be accessed via SSL. Any
> URL that does not match the pattern can be accessed over *either* SSL or
> non-SSL.
>
> One additional note -- web applications that allow a user to switch from
> SSL back to non-SSL on the same session are broken. What you've just done
> is allowed anyone snooping the network to swipe the session id and
> impersonate your user (for example, click the "buy" button again using the
> credit card number that was entered on a secure page).
>
> You should program your apps that, once a user switches from non-SSL to
> SSL, you never again accept a non-SSL request for that same session id.
> If the user needs to go back (for example, after checking out of an
> ecommerce site you want to buy some more stuff), start a new session first
> (and clear the confidential data you might have captured).
>
> > Thanks!
>
> Craig
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 3 Dec 2002, Alexander Wallace wrote:
> Date: 03 Dec 2002 10:21:19 -0600
> From: Alexander Wallace <to...@rwsoft-online.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Filters don't affect request dispatcher forward
>
> 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..
>
I'm not sure what you're really asking, but ...
If you declare a security constraint with a transport guarantee, any URL
that matches the specified pattern(s) can *only* be accessed via SSL. Any
URL that does not match the pattern can be accessed over *either* SSL or
non-SSL.
One additional note -- web applications that allow a user to switch from
SSL back to non-SSL on the same session are broken. What you've just done
is allowed anyone snooping the network to swipe the session id and
impersonate your user (for example, click the "buy" button again using the
credit card number that was entered on a secure page).
You should program your apps that, once a user switches from non-SSL to
SSL, you never again accept a non-SSL request for that same session id.
If the user needs to go back (for example, after checking out of an
ecommerce site you want to buy some more stuff), start a new session first
(and clear the confidential data you might have captured).
> Thanks!
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by Alexander Wallace <to...@rwsoft-online.com>.
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 <to...@rwsoft-online.com>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: Tomcat Users List <to...@jakarta.apache.org>
> > 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Filters don't affect request dispatcher forward
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 2 Dec 2002, Alexander Wallace wrote:
> Date: 02 Dec 2002 18:41:26 -0600
> From: Alexander Wallace <to...@rwsoft-online.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>