On Fri, 4 Jan 2002, John Yu wrote:
> Date: Fri, 04 Jan 2002 18:09:59 +0800
> From: John Yu <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Forced URL rewriting
>
> Correct me if I'm wrong. Isn't the enable-ness of the URL rewrite the
> responsibility of the container, not Struts?
>
The spec language that is relevant here (quoting from Servlet 2.3, Section
7.1.4):
Web containers must be able to support HTTP session while
servicing HTTP requests from clients that do not support
the use of cookies. To fulfill this requirement, web
containers commonly support the URL rewriting mechanism.
Thus, a container should only allow turning off of URL rewriting *if* it
has some other mechanism to support sessions without cookies. Tomcat
currently doesn't have such an alternative mechanism.
> Recently, we had a project using Struts with Weblogic. Weblogic has an
> option in its proprietary weblogic.xml descriptor to turn off URL rewrite.
> We tried it and it worked. No more 'jsessionid' appeared on the URL.
>
> (We tried this because our client was worried that the app users would try
> to cut and paste the session id from one PC to another and compromise the
> security...)
>
IMHO, this is an entirely insufficient argument for turning off URL
rewriting. You've got equivalent security issues with cookies -- the only
difference is you cannot see them visibly. You should be using things
like the transaction token support in Struts to avoid problems of
inadvertent cut-and-paste of URLs that include session ids, while also
dealing with pesky things like back-arrows and resubmits of the same form.
> Then, shouldn't Tomcat provide the same option?
No, because it would violate the spec requirement quoted above.
> --
> John
>
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
