You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by John Yu <jo...@scioworks.com> on 2002/01/04 11:09:59 UTC
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?
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...)
Then, shouldn't Tomcat provide the same option?
--
John
At 06:52 pm 23-12-2001 -0800, you wrote:
>On Sun, 23 Dec 2001, Ted Husted wrote:
>
> > Date: Sun, 23 Dec 2001 06:57:35 -0500
> > From: Ted Husted <hu...@apache.org>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: struts-dev@jakarta.apache.org
> > Subject: Forced URL rewriting
> >
> > There was a question on the list a while back regarding URL rewriting
> > and clustered servers that I didn't have a good answer for. Basically,
> > they want to avoid maintaining the session, apparently as a performance
> > tweak. (What I don't know is whether that would actually make a
> > difference in real life.)
> >
> > But, should the tags have an option to supress rewriting (and just
> > lookup the path)?
> >
> > Ideally, you'd think this should fall on the container. The spec does
> > require an option to disable cookies, but not so much url rewriting
> > (when supported). You could turn this off in Resin, but apparently not
> > in Tomcat, and who knows about the others?
> >
> > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg17727.html
> >
>
>Sessions are NOT required by the servlet or JSP specifications -- to make
>them go away in your application, you should simply don't create a session
>(in your servlet), and every JSP page needs to start with:
>
> <%@ page session="false" %>
>
>in order to avoid the default JSP behavior of creating a session.
>
>If you are not in a session, URL rewriting won't change the argument -- it
>will be returned unchanged (just as it is when you are in a session but
>the container knows that you are using cookies). Providing a
>configuration option to make the various Struts tags not call encodeURL()
>would be technically feasible, but IMHO it would have a vanishingly small
>impact on performance so I cannot see it being worth the bother.
>
>Whether omitting sessions entirely has a performance benefit is impossible
>to generalize - it depends very much on how your application server
>implements sessions, as well as what you store in them. You also have to
>consider the extra cost of the alternatives you employ to deal with the
>absence of sessions (such as extra hidden variables in your pages, and/or
>storing user state information in a database or EJB). There is no general
>rule on what's best.
>
>You should also note that some container features (such as form-based
>login) require sessions to be useful. In addition, the following Struts
>features cannot operate in the absence of sessions:
>* Per-user localization (<bean:message> and friends)
>* Transaction tokens to catch resubmits of the same form
> because of the back arrow
>* Maintaining form beans across multiple pages (without
> having all of the properties represented as hidden properties
> on every single page).
>
>My experience has been that the scalability issues people run into with
>sessions are more related to keeping too many session attributes around
>for too long, and not due to the existence of the session itself. In a
>distributed environment, there is some amount of overhead (sessions will
>need to be "sticky" to a particular server), but the tradeoffs for what
>sessions buy you needs to be balanced against this cost.
>
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel +1 716 737-3463
> > -- http://www.husted.com/struts/
> >
>
>Craig McClanahan
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Rapid WebApp Assembly for Struts"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Forced URL rewriting
Posted by Ted Husted <hu...@apache.org>.
That's the only way you can test to see if cookies are enabled, and
still maintain the session if they are not. There's no handshaking in
HTTP, so the container tries both cookies and URL rewriting on the first
request, and then forgoes URL rewriting if it sees the client took the
cookie.
I imagine that, if you had to, you could work around this using a
redirect or something, to get quickly past the initial request, and make
an independant check for cookies.
-T.
John Yu wrote:
> Btw, there's something I'm not too sure. I suppose if cookie is enabled,
> URL rewrite will not happen. However, on Weblogic, with cookie on, it
> always does URL rewrite after the first login Action. (But the rest pages
> are ok.) That's why we turn off URL rewrite with cookie turned on.
>
> --
> John Yu Scioworks Technologies
> e: john@scioworks.com w: +(65) 873 5989
> w: http://www.scioworks.com m: +(65) 9782 9610
>
> Scioworks Camino - "Rapid WebApp Assembly for Struts"
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Forced URL rewriting
Posted by Martin Cooper <ma...@tumbleweed.com>.
The first request in a session will always result in a rewritten URL *and* a
cookie being returned to the browser. That's because the servlet container
does not yet know if the browser has cookies enabled, so it returns both. On
the second request, the container will see the cookie, if cookies are
enabled, and stop rewriting URLs. If the container didn't get the cookie
back, then it will continue to rewrite the URLs.
See section 7.1 of the Servlet spec for more on this.
--
Martin Cooper
----- Original Message -----
From: "John Yu" <jo...@scioworks.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Sunday, January 06, 2002 7:37 PM
Subject: Re: Forced URL rewriting
> At 10:15 am 04-01-2002 -0800, you wrote:
> > > 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.
>
>
> Well, making it invisible does help a bit. "Security by Obscurity!" :-)
>
> Btw, there's something I'm not too sure. I suppose if cookie is enabled,
> URL rewrite will not happen. However, on Weblogic, with cookie on, it
> always does URL rewrite after the first login Action. (But the rest pages
> are ok.) That's why we turn off URL rewrite with cookie turned on.
>
>
> --
> John Yu Scioworks Technologies
> e: john@scioworks.com w: +(65) 873 5989
> w: http://www.scioworks.com m: +(65) 9782 9610
>
> Scioworks Camino - "Rapid WebApp Assembly for Struts"
>
>
> --
> 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: Forced URL rewriting
Posted by John Yu <jo...@scioworks.com>.
Thanks, Ted and Martin.
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Rapid WebApp Assembly for Struts"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Forced URL rewriting
Posted by John Yu <jo...@scioworks.com>.
At 10:15 am 04-01-2002 -0800, you wrote:
> > 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.
Well, making it invisible does help a bit. "Security by Obscurity!" :-)
Btw, there's something I'm not too sure. I suppose if cookie is enabled,
URL rewrite will not happen. However, on Weblogic, with cookie on, it
always does URL rewrite after the first login Action. (But the rest pages
are ok.) That's why we turn off URL rewrite with cookie turned on.
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Rapid WebApp Assembly for Struts"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Forced URL rewriting
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 4 Jan 2002, Donnie Hale wrote:
> Date: Fri, 4 Jan 2002 19:49:30 -0500
> From: Donnie Hale <do...@haleonline.net>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: RE: Forced URL rewriting
>
> Craig,
>
> I think the point is that WebLogic meets the spec criteria but, for the
> application in question it was decided to turn off cookie-less support via
> URL rewriting. Thus users of the application must have cookies enabled. That
> doesn't reflect at all on the container's spec compliance, just the choice
> of that particular app development team.
>
The official rules for J2EE spec compliance (which includes Servlet and
JSP) go into quite a bit of detail about what containers can and cannot
do. Having configuration settings that allow the container to break the
rules (which would be true if we added this switch to Tomcat, since it
doesn't support any alternative way to provide cookie-less sessions) are
on the official no-no list.
I don't know whether WebLogic meets this requirement or not ... but
Tomcat's code has *my* name on a lot of the code commits :-).
> Perhaps obvious...
>
> Donnie
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Forced URL rewriting
Posted by Ted Husted <hu...@apache.org>.
The spec says cookies take precedence, so if the application requires
cookies, it can just test for cookies.
Donnie Hale wrote:
>
> It not being a spec issue anymore is the point I was trying to make. I agree
> with you that using security as the reason is a little silly. However, from
> the standpoint of bookmarking and corporate intranet apps and their
> corresponding help desk support issues, I can see requiring cookies and
> disallowing URL rewriting at the app level. Note that the original poster
> mentioned that the weblogic setting is in the "weblogic.xml" file. That
> file, in case you're not aware, is a WebLogic-proprietary deployment
> descriptor file for a web application that goes in the WEB-INF directory
> along with web.xml. So, in the same container VM, one web app could have URL
> rewriting on and another have it off.
>
> Donnie
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Friday, January 04, 2002 8:34 PM
> > To: Struts Developers List
> > Subject: RE: Forced URL rewriting
> >
> >
> >
> >
> > On Fri, 4 Jan 2002, Donnie Hale wrote:
> >
> > > Date: Fri, 4 Jan 2002 19:49:30 -0500
> > > From: Donnie Hale <do...@haleonline.net>
> > > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > > To: Struts Developers List <st...@jakarta.apache.org>
> > > Subject: RE: Forced URL rewriting
> > >
> > > Craig,
> > >
> > > I think the point is that WebLogic meets the spec criteria but, for the
> > > application in question it was decided to turn off cookie-less
> > support via
> > > URL rewriting. Thus users of the application must have cookies
> > enabled. That
> > > doesn't reflect at all on the container's spec compliance, just
> > the choice
> > > of that particular app development team.
> > >
> >
> > And, of course, it *would* be legal for an *application* to not support
> > URL rewriting -- which is why it's perfectly legitimate to consider such a
> > switch on Struts itself. Even for that purpose, though, I'm inclined
> > against it -- the reason from the original proposer (security concerns) is
> > not persuasive to me -- but it's not a spec issue any more.
> >
> > > Perhaps obvious...
> > >
> > > Donnie
> > >
> >
> > 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>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Forced URL rewriting
Posted by Donnie Hale <do...@haleonline.net>.
It not being a spec issue anymore is the point I was trying to make. I agree
with you that using security as the reason is a little silly. However, from
the standpoint of bookmarking and corporate intranet apps and their
corresponding help desk support issues, I can see requiring cookies and
disallowing URL rewriting at the app level. Note that the original poster
mentioned that the weblogic setting is in the "weblogic.xml" file. That
file, in case you're not aware, is a WebLogic-proprietary deployment
descriptor file for a web application that goes in the WEB-INF directory
along with web.xml. So, in the same container VM, one web app could have URL
rewriting on and another have it off.
Donnie
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Friday, January 04, 2002 8:34 PM
> To: Struts Developers List
> Subject: RE: Forced URL rewriting
>
>
>
>
> On Fri, 4 Jan 2002, Donnie Hale wrote:
>
> > Date: Fri, 4 Jan 2002 19:49:30 -0500
> > From: Donnie Hale <do...@haleonline.net>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > Subject: RE: Forced URL rewriting
> >
> > Craig,
> >
> > I think the point is that WebLogic meets the spec criteria but, for the
> > application in question it was decided to turn off cookie-less
> support via
> > URL rewriting. Thus users of the application must have cookies
> enabled. That
> > doesn't reflect at all on the container's spec compliance, just
> the choice
> > of that particular app development team.
> >
>
> And, of course, it *would* be legal for an *application* to not support
> URL rewriting -- which is why it's perfectly legitimate to consider such a
> switch on Struts itself. Even for that purpose, though, I'm inclined
> against it -- the reason from the original proposer (security concerns) is
> not persuasive to me -- but it's not a spec issue any more.
>
> > Perhaps obvious...
> >
> > Donnie
> >
>
> 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: Forced URL rewriting
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 4 Jan 2002, Donnie Hale wrote:
> Date: Fri, 4 Jan 2002 19:49:30 -0500
> From: Donnie Hale <do...@haleonline.net>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: RE: Forced URL rewriting
>
> Craig,
>
> I think the point is that WebLogic meets the spec criteria but, for the
> application in question it was decided to turn off cookie-less support via
> URL rewriting. Thus users of the application must have cookies enabled. That
> doesn't reflect at all on the container's spec compliance, just the choice
> of that particular app development team.
>
And, of course, it *would* be legal for an *application* to not support
URL rewriting -- which is why it's perfectly legitimate to consider such a
switch on Struts itself. Even for that purpose, though, I'm inclined
against it -- the reason from the original proposer (security concerns) is
not persuasive to me -- but it's not a spec issue any more.
> Perhaps obvious...
>
> Donnie
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Forced URL rewriting
Posted by Donnie Hale <do...@haleonline.net>.
Craig,
I think the point is that WebLogic meets the spec criteria but, for the
application in question it was decided to turn off cookie-less support via
URL rewriting. Thus users of the application must have cookies enabled. That
doesn't reflect at all on the container's spec compliance, just the choice
of that particular app development team.
Perhaps obvious...
Donnie
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Friday, January 04, 2002 1:15 PM
> To: Struts Developers List
> Subject: Re: Forced URL rewriting
>
>
>
>
> On Fri, 4 Jan 2002, John Yu wrote:
>
> > Date: Fri, 04 Jan 2002 18:09:59 +0800
> > From: John Yu <jo...@scioworks.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > 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:
<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: Forced URL rewriting
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 4 Jan 2002, John Yu wrote:
> Date: Fri, 04 Jan 2002 18:09:59 +0800
> From: John Yu <jo...@scioworks.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>