Having the session ID in the URL is a concern if your site includes
links to unknown third party sites (e.g. if you're displaying email with
links in); you open yourself up to a 'referrer attack', where a
malicious user can hijack your session by getting you to click a link to
his site and examining his referrer logs. That's one reason cookies are
the preferred mechanism.
L.
David G. Friedman wrote:
Bernhard,
Does it really matter? In most Java application servers, don't they do both
for the first request but after the second
request, where cookies are detected to be on, they stop using url rewriting.
Or do those first two communications scare
you? ;) Besides, a packet sniffer could see the cookie being transmitted every
time anyway so does it really matter if
the cookie is in the browser URL line or being transmitted before the URL in
the cookie header value for the HTTP
request call?
Regards,
David
-----Original Message-----
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 24, 2006 3:26 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.
-----Ursprüngliche Nachricht-----
Von: David G. Friedman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Januar 2006 18:10
What do you mean by "do it the other way around" ?
Well I mean that you ONLY use cookies for the session management and not URL
Rewriting, you might want to do that for security reason, because when using
URL Rewriting the Session ID is in the address line and the cache, so a
pssoble security risk.
I think this should be contollable in a standard way and not
container-specific.
Bernhard
-----Original Message-----
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 11:34 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.
Thank you!
But it's not possible to do it the other way round in Tomcat right ?
Also I think this should belong in the web.xml and shouldn't be
container-specific, what do you think?
Bernhard
-----Ursprüngliche Nachricht-----
Von: David G. Friedman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Januar 2006 17:28
An: Struts Users Mailing List
Betreff: RE: Forcing URL Rewriting over Cookies in an existing
application.
The same thing (disable cookies but enable url rewriting)
should work on Tomcat 4.X and 5.X. See the "cookies"
attribute in the below url(s):
http://tomcat.apache.org/tomcat-4.0-doc/config/context.html
http://tomcat.apache.org/tomcat-5.0-doc/config/context.html
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
Regards,
David
-----Original Message-----
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 11:20 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.
OT, but I'm interested, is this available im Tomcat too?
Thanks
Bernhard
-----Ursprüngliche Nachricht-----
Von: David G. Friedman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Januar 2006 17:08
An: Struts Users Mailing List
Betreff: RE: Forcing URL Rewriting over Cookies in an existing
application.
http://access1.sun.com/techarticles/sessions.iws.html
Regards,
David
-----Original Message-----
From: Jay [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 10:53 AM
To: user@struts.apache.org
Subject: Forcing URL Rewriting over Cookies in an existing
application.
Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02
(I guess)) that uses Cookies for session handling and has
been so for around 3/4 years. I have a requirement where I
want to force URL Rewriting even if the browser supports
cookies. Please help! Jay
Broadband interface (RIA) + mail box saftey =
http://Struts_User_List.roomity.com
*Your* clubs, no sign up to read, ad supported; try broadband
internet.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
