On 01/29/09 03:59, Paul Carter-Brown wrote:
> Hi,
>
> Sorry I was away yesterday and could not reply. I agree that option 1
> should be the default in Glassfish and having 2 parameters would
> provide developers will granular control of how they want
> rewriting/cookies to be handled.
>
> Thanks so much,
Thanks, Paul! I'm glad we're in agreement.
As you have probably seen from other emails, I have already fixed this
in the upcoming
GlassFish v3, and provided a patch for people to try out with GlassFish
v2.1 (hopefully, this
patch can be folded into an official patch or update release for
GlassFish v2.1).
Thanks for all your input, which has helped shape the final solution.
Jan
>
> Paul
>
>
> -----Original Message-----
> *From*: Jan Luehe <Jan.Luehe_at_Sun.COM
> <mailto:Jan%20Luehe%20%3cJan.Luehe_at_Sun.COM%3e>>
> *Reply-to*: Jan.Luehe_at_Sun.COM
> *To*: users_at_glassfish.dev.java.net
> <mailto:users_at_glassfish.dev.java.net>, webtier_at_glassfish.dev.java.net
> <mailto:webtier_at_glassfish.dev.java.net>
> *Cc*: paul.carter-brown_at_smilecoms.com
> <mailto:paul.carter-brown_at_smilecoms.com>
> *Subject*: Re: [webtier] Re: How to prevent Glassfish v2 to rewrite
> urls with jsessionid?
> *Date*: Tue, 27 Jan 2009 17:52:23 -0800
>
> Hi Joerg,
>
> On 01/27/09 17:15, glassfish_at_javadesktop.org
> <mailto:glassfish_at_javadesktop.org> wrote:
>> Hi Jan!
>>
>> My feedback on the four cases as following. It comes to my mind that this is a sensible topic and one should be aware/announce/discuss/test that as one might not know all the interactions regarding all projects/products running on glassfish/dev.net e.g.
>> ! web service(stateful/stateless) products
>> ! Authorization/Authentication products
>> ! Clustering/Session transfer/Load balancing
>>
>> [i]Case 1:
>> enableCookies: true
>> enableURLRewriting: true
>> -> jsessionid of new session stored in cookie *and* encoded in URL[/i]
>>
>> -1: Pls see "http://mail-archives.apache.org/mod_mbox/tomcat-users/200211.mbox/%3C3DDF619B.6020507@btopenworld.com%3E" <http://mail-archives.apache.org/mod_mbox/tomcat-users/200211.mbox/%3C3DDF619B.6020507@btopenworld.com%3E>. Expected standard behaviour should be:(1)[i]>>>Tomcat does indeed know if a session id cookie was received (and you can
>>
>>
>>>>> find out as well, by calling request.isSessionIdFromCookie()). If that is
>>>>> the case, response.encodeURL() and response.encodeRedirectURL() will
>>>>> return the argument unmodified.[/i]
>>>>>
>>>>>
>> ...else the jsessionid is encoded.
>>
>> BUT (2)[i]">>>One subtlety should be pointed out, though -- consider what happens on the
>>
>>
>>>>> very first response for a new session. At that point in time, Tomcat has
>>>>> no idea whether the client supports cookies or not. Therefore, it sends
>>>>> the session id both ways (rewriting and a cookie). On subsequent
>>>>> requests, if the cookie has been returned, Tomcat will stop rewriting."[/i]
>>>>>
>>>>>
>> ...hence if isSessionNew write cookie and encode url.
>>
>
> Right, but IT 3972 complained about the fact that there was no way to
> disable the
> encoding of the jsessionid in this case. This is where the
> "enableURLRewriting" property
> in sun-web.xml (a GlassFish enhancement over Tomcat) will become
> relevant, see below.
>
>> On next request, behaviour(1) is in effect. So if cookie is transmitted on the next request, cookie supersedes url-rewriting.
>>
>>
>
> I completely agree with you. When I listed the various cases, I was
> only concerned about the
> isSessionNew case (that's what I meant by "jsessionid of new
> session"). That is what IT 3972
> was all about. I'm not talking about subsequent requests: For those,
> the presence of a cookie
> will supersede any "enableURLRewriting" setting. Sorry if I was not
> clear.
>
> What was needed was a way to disable URL rewriting for a newly created
> session. With the fix for
> IT 3972, URL rewriting was disabled by the mere presence of
> "enableCookies=true". But as Paul
> pointed out, this behaviour was too coarse-grained. This is now fixed
> by adding support for the
> "enableURLRewriting" property. In fact, I've changed the URL rewriting
> code in Response.java
> (isEncodeable) as follows:
>
> Index: Response.java
> ===================================================================
> --- Response.java (revision 24476)
> +++ Response.java (working copy)
> @@ -1503,8 +1503,8 @@
> return (false);
> }
> if (hreq.isRequestedSessionIdFromCookie() ||
> - (getContext() != null && getContext().getCookies())) {
> - return (false);
> + (getContext() != null &&
> !getContext().isEnableURLRewriting())) {
> + return false;
> }
>
> As you can see, URL rewriting will now be disabled if the request
> carried a JSESSIONID
> cookie (to resume a session) or URL rewriting has been disabled (by
> setting "enableURLRewriting"
> in sun-web.xml to false).
>
> org.apache.catalina.Context#isEnableURLRewriting() is a new method I
> added, which returns the
> value of the "enableURLRewriting" property in sun-web.xml.
>
>> Case 2:
>> enableCookies: true
>> enableURLRewriting: false
>> -> jsessionid of new session only stored in cookie (and not encoded in URL)
>> +1: But be aware/DOCUMENT that this can lead to loss/regeneration of session tracking if client does not accept cookies. Countermeasure in j2ee web layer project could be sending a redirect (plus adding a special http param for recognition purpose, else endless redirects) from a filter and then checking for cookie. BTW in the J2EE Tutorial these options are never mentioned/linked. One hint more that Case 1 should stay the default behaviour.
>>
>>
> Yes.
>> Case 3:
>> enableCookies: false
>> enableURLRewriting: true
>> -> jsessionid of new session only encoded in URL (and not stored in cookie)
>> +1: Especiall unit-test that a session cookie might still be sent in(e.g. cookie still valid out there on the browsers) but dev team opted to turn cookie sending off and redeployed. Okay, this might be more an in-development-case, but anyway.,, :-)
>>
>>
>
> Agreed. In fact, our request processing code already does this: Don't
> go looking for JSESSIONID cookies if
> "enableCookies" has been set to false.
>> Case 4:
>> enableCookies: false
>> enableURLRewriting: false
>> -> invalid
>> -1: There might be projects out there which A) need no session tracking/stateless webapp OR B) opt for other session generation mechanism (?SSL session, custom,...). Developer is in charge to create web-session anyway, its not generated "automagically". Deployment MUST hence still be possible.
>>
>>
>
> OK, good point. Notice that GlassFish does not (yet) support session
> tracking via SSL id, see
> this RFE: https://glassfish.dev.java.net/issues/show_bug.cgi?id=4589
> ("Add support for session tracking via SSL session id"), but I agree
> that disabling both cookies
> and URL rewriting should be possible in order to support any custom
> tracking scheme.
>
> Thanks so much for your feedback and comments, Joerg!
> They have been very useful. :)
>
>
> Jan
>
>
>
>> Jörg
>> [Message sent by forum member 'joma_javanet' (joma_javanet)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=328536
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net <mailto:users-unsubscribe_at_glassfish.dev.java.net>
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net <mailto:users-help_at_glassfish.dev.java.net>
>>
>>
>>
>