Skip to main content

How to prevent Glassfish v2 to rewrite urls with jsessionid?

25 replies [Last post]
bouteill
Offline
Joined: 2004-07-02

Hello,
Is there anyway to prevent Glassfish v2 from rewriting urls with jsessionid?
(Yes, we don't care about clients who don't support cookies :).
The problem is that even when the web client supports cookies, it seems that links generated on the first page of an http session are rewritten w/ ?jsessionid=12345678790 and this is a concern from an SEO standpoint when crawlers come to our site.
Is there some technical reason why the links on the first page have to be encoded with jsessionid?
If not, how can you prevent it?
sun-web.xml (see http://forums.java.net/jive/message.jspa?messageID=246916) doesn't seem to be supported in v2?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bouteill
Offline
Joined: 2004-07-02

Ok, Hi! Original thread creator here :)
I'm trying to follow what you guys are saying and I want to make sure I get it right.
Are you saying the fix we got caused regressions for other customers and you plan to revert it expecting us to now use enableURLRewriting=false to get the behavior we want?
So we should make the following change to our sun-web.xml:

>
>
>
>

which should cause no change in behavior for us on 9.1.2.5 now, but will take effect and do what we want whenever your change is rolled in a future service pack?
Thanks for clarifying.

Jan Luehe

On 01/30/09 15:26, glassfish@javadesktop.org wrote:
> Ok, Hi! Original thread creator here :)
>
Yes, I remember you! :)
> I'm trying to follow what you guys are saying and I want to make sure I get it right.
> Are you saying the fix we got caused regressions for other customers and you plan to revert it expecting us to now use enableURLRewriting=false to get the behavior we want?
> So we should make the following change to our sun-web.xml:
>
>
>>
>>
>>
>>

>>
>
> which should cause no change in behavior for us on 9.1.2.5 now, but will take effect and do what we want whenever your change is rolled in a future service pack?
> Thanks for clarifying.
>

You got it exactly right.

(Notice that "enableCookies" has always been, and will remain "true" by
default,
so you could remove it from your sun-web.xml. )

Thanks for following up!

Jan

> [Message sent by forum member 'bouteill' (bouteill)]
>
> http://forums.java.net/jive/thread.jspa?messageID=329334
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
webtier@glassfish.dev.java.net
[att1.html]

joma_javanet
Offline
Joined: 2004-12-06

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". 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. On next request, behaviour(1) is in effect. So if cookie is transmitted on the next request, cookie supersedes url-rewriting.

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.

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.,, :-)

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.

Jörg

Jan Luehe

Hi Joerg,

On 01/27/09 17:15, glassfish@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". 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@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

[att1.html]

joma_javanet
Offline
Joined: 2004-12-06

Hi Jan!

Looks to me like all is sorted out..for glassfish v3.

I am stuck with this very question at a current productive project(Server 9.1.1 (build b58-fcs)). Can you make a patch against the 2.1 sources also?

Jörg

Jan Luehe

Hi Joerg,

On 01/28/09 01:29, glassfish@javadesktop.org wrote:
> Hi Jan!
>
> Looks to me like all is sorted out..for glassfish v3.
>
> I am stuck with this very question at a current productive project(Server 9.1.1 (build b58-fcs)). Can you make a patch against the 2.1 sources also?
>

I will, sometime today.
Hopefully, the diffs can be folded into a 9.1.1 patch/update release.

Thanks for your patience,

Jan

> Jörg
> [Message sent by forum member 'joma_javanet' (joma_javanet)]
>
> http://forums.java.net/jive/thread.jspa?messageID=328588
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jan Luehe

Hi Joerg,

On 01/28/09 11:27, Jan Luehe wrote:
> Hi Joerg,
>
> On 01/28/09 01:29, glassfish@javadesktop.org wrote:
>> Hi Jan!
>>
>> Looks to me like all is sorted out..for glassfish v3.
>> I am stuck with this very question at a current productive
>> project(Server 9.1.1 (build b58-fcs)). Can you make a patch against
>> the 2.1 sources also?
>>
>
> I will, sometime today.
> Hopefully, the diffs can be folded into a 9.1.1 patch/update release.

Can you try the attached patch (created against the 9.1.1 FCS codebase),
by storing it somewhere in your filesystem and adding the path to it to your
domain's classpath-prefix (I assume you are not running in a cluster env)?

Let me know if you have any questions regarding the patch or how to
apply it.

Please let me know.

Thanks,

Jan

>
>> Jörg
>> [Message sent by forum member 'joma_javanet' (joma_javanet)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=328588
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

[patch.jar]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

huancon
Offline
Joined: 2010-04-09

Hi , I had found the old post and think maybe you can help me.
We are migrating the app from weblogic to glassfish v2. and one of the program fail. After debug, we find that the sessionid which initiated from one jsp, then the same sessionid pass to a function in ejb. In this function, it generate the URL based on the sessionid, but when this URL run, the sessionid change, it create a new sessionid. Please see the code of the function below. Do you have any idea why glassfish did not maintain the sessionid? Thanks.

public boolean sendURLOutStreamByEmail(String[] pageName, String[] fileName, String toEmail, String emailSubject, String sessionId, String baseURL) {
File[] files = new File[fileName.length];
String[] fullName = new String[fileName.length];
String filePrefix = null;

try{
String parentDir = getTmpDir();
for (int i = 0; i < pageName.length; i++) {
String url = baseURL + pageName[i] +"&JSESSIONID="+sessionId;

filePrefix = parentDir;//fundIds[i] ;
System.out.println("URL is" + url);
System.out.println("Generating xls...................filePrefix is" + filePrefix);
fileName[i] = fileName[i] + ".xls";
fullName[i] = filePrefix + fileName[i];
System.out.println("file name is" + fileName[i]);
System.out.println("full name is" + fullName[i]);
files[i] = new File(fullName[i]);
System.out.println("file absolute path is "+ files[i].getAbsolutePath());
BufferedWriter fileout = new BufferedWriter(new FileWriter(files[i]));
InputStream in = new URL(url).openStream();
InputStreamReader inR = new InputStreamReader( in );
BufferedReader buf = new BufferedReader( inR );
String line;
while ( ( line = buf.readLine() ) != null ) {
fileout.write(line);

}

joma_javanet
Offline
Joined: 2004-12-06

Is session rewriting and session cookies an either or way in glassfish?
Tried to set


in my sun-web.xml. But this fix prevents that jsession id is appended in encode(Redirect)URL/CoyoteResponse. hreq.isRequestedSessionIdFromCookie() returns false BUT getContext().getCookies() is true and prevents the rewrite!!!

if (hreq.isRequestedSessionIdFromCookie() ||
(getContext() != null && getContext().getCookies()))

Jan Luehe

On 01/27/09 03:03, glassfish@javadesktop.org wrote:
> Is session rewriting and session cookies an either or way in glassfish?
> Tried to set
>
>
>
>

> in my sun-web.xml. But this fix prevents that jsession id is appended in encode(Redirect)URL/CoyoteResponse. hreq.isRequestedSessionIdFromCookie() returns false BUT getContext().getCookies() is true and prevents the rewrite!!!
>
> if (hreq.isRequestedSessionIdFromCookie() ||
> (getContext() != null && getContext().getCookies()))
>

The

getContext() != null && getContext().getCookies()

check was added in order to address

https://glassfish.dev.java.net/issues/show_bug.cgi?id=3972
("HttpServletResponse.encodeURL() unconditionally appends jsessionid
if session is newly created")

This means that you must remove this line from your sun-web.xml:

if you want the jsessionid to be included in the rewritten URL.

See also https://glassfish.dev.java.net/issues/show_bug.cgi?id=7091

Thanks,

Jan

> [Message sent by forum member 'joma_javanet' (joma_javanet)]
>
> http://forums.java.net/jive/thread.jspa?messageID=328357
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jan Luehe

On 01/27/09 11:24, Jan Luehe wrote:
> On 01/27/09 03:03, glassfish@javadesktop.org wrote:
>> Is session rewriting and session cookies an either or way in
>> glassfish? Tried to set
>>
>>
>>

>> in my sun-web.xml. But this fix prevents that jsession id is appended
>> in encode(Redirect)URL/CoyoteResponse.
>> hreq.isRequestedSessionIdFromCookie() returns false BUT
>> getContext().getCookies() is true and prevents the rewrite!!!
>>
>> if (hreq.isRequestedSessionIdFromCookie() ||
>> (getContext() != null && getContext().getCookies()))
>>
>
> The
>
> getContext() != null && getContext().getCookies()
>
> check was added in order to address
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=3972
> ("HttpServletResponse.encodeURL() unconditionally appends jsessionid
> if session is newly created")
>
> This means that you must remove this line from your sun-web.xml:
>
>
>
> if you want the jsessionid to be included in the rewritten URL.
>
> See also https://glassfish.dev.java.net/issues/show_bug.cgi?id=7091

Sorry, I just realized this open bug:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=4394
("server log message says enableURLRewriting is not supported")

which I had evaluated as follows:

The "enableURLRewriting" property is completely redundant and is
currently ignored by the container.

The only relevant property is "enableCookies". Setting it to false
automatically enables url rewriting (which is why url rewriting worked
for you).

Not sure why 2 properties are needed for the same thing. :(

Therefore, rather than removing

from your sun-web.xml, you should keep it and set it to "false" (as I
recommended in https://glassfish.dev.java.net/issues/show_bug.cgi?id=7091),
while removing

because "enableURLRewriting" is ignored in GlassFish v2.1.

In GlassFish v3, I will add support for "enableURLRewriting" such that
it and "enableCookies" are mutually exclusive: If both are present in a
webapp's sun-web.xml and set to the same value, deployment of the webapp
will fail.

Hope this helps.

Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

joma_javanet
Offline
Joined: 2004-12-06

Hi Jan!

Read your answer carefully and agree to your argument that two properties are redundant - only IF glassfish should support EITHER cookies OR URL Rewriting.

But in my opinion glassfish could and should support BOTH behaviors in parallel as well as let the dev opt for either or. My case is a current webapp where some client browsers MAY deny cookies while others will accept them.

Currently I cant serve both clients but rather have to decide A) to choose the common denominator - url rewriting - which works for both client browsers OR B) work with cookies and deny service to not-accepting clients, telling them to enable cookies.

I did not dig into the specs for j2ee server session tracking behavior but otherwise stated i do not see a reason why "BOTH behaviors in parallel" should not be possible. A hint to this, contrary to your opinion, is that currently TWO properties are specified in session manager properties. On the other side i do wonder why since nearly one year nobody has objected, or at least unit-tested, what i am suspecting, to be a bug.

Jörg

P.S. Did dig into JSR-000154 JavaTM Servlet 2.5 Specification
(Maintenance Release 2), quoting [i]"SRV.7.1.4 Session Integrity
Web containers must be able to support the 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." [/i]

P.S. added.

Message was edited by: joma_javanet

Jan Luehe

Hi Joerg,

On 01/27/09 13:37, glassfish@javadesktop.org wrote:
> Hi Jan!
>
> Read your answer carefully and agree to your argument that two properties are redundant - only IF glassfish should support EITHER cookies OR URL Rewriting.
>
> But in my opinion glassfish could and should support BOTH behaviors in parallel as well as let the dev opt for either or. My case is a current webapp where some client browsers MAY deny cookies while others will accept them.
>
> Currently I cant serve both clients but rather have to decide A) to choose the common denominator - url rewriting - which works for both client browsers OR B) work with cookies and deny service to not-accepting clients, telling them to enable cookies.
>
> I did not dig into the specs for j2ee server session tracking behavior but otherwise stated i do not see a reason why "BOTH behaviors in parallel" should not be possible. A hint to this, contrary to your opinion, is that currently TWO properties are specified in session manager properties. On the other side i do wonder why since nearly one year nobody has objected, or at least unit-tested, what i am suspecting, to be a bug.
>

Thanks for bringing this up!

I just had an email exchange with Paul Carter-Brown (cc'ed) regarding
this very topic.

This is what Paul wrote:

> Hi,
>
> I changed the setting and it now works without cookies. My assumptions
> were correct however in that if I enable cookies on the browser, the
> server still rewrites URL's. Personally I think that the way it was
> before was much better in that the server effectively assumes the
> worst case (there is no cookie support) and rewrites the first URL and
> sets a cookie. If a request has a cookie, then it would no longer
> rewrite the urls. This is the way all other web containers do it so I
> dont see why Glassfish should be any different. The link you attached
> shows that the initial problem people had could have been erradicated
> by turning off URL rewriting in their setups as opposed to regressing
> the default setup.

... and this is how I replied:

--- BEGIN REPLY ---
The link mentioned that people were concerned about the security
implications of exposing
a jsessionid inside a URL when they were not expecting the URL to be
rewritten (since their
webapp was declared to support cookies, via "enableCookies" set to "true").

In the case referred to by the link, people did not want the jsessionid
to be encoded in the URL.
They were under the impression that by setting "enableCookies" to
"true", their concerns
would be addressed.

There was no way for them to express that they wanted to disable URL
rewriting other than
by setting "enableCookies" to "true" (since "enableURLRewriting" was
being ignored at the time
the issue was filed).

Now that I think about it, maybe "enableURLRewriting" should be a
property in its own right,
and it should be possible to set both "enableCookies" and
"enableURLRewriting" to true at the
same time. The way I just fixed
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4394
("server log message says enableURLRewriting is not supported") in
GlassFish v3 is to treat
this as an error case, but maybe that's too restrictive.

Perhaps both properties should be supported, with these semantics:

Case 1:
enableCookies: true
enableURLRewriting: true
-> jsessionid of new session stored in cookie *and* encoded in URL

Case 2:
enableCookies: true
enableURLRewriting: false
-> jsessionid of new session only stored in cookie (and not encoded in URL)

Case 3:
enableCookies: false
enableURLRewriting: true
-> jsessionid of new session only encoded in URL (and not stored in cookie)

Case 4:
enableCookies: false
enableURLRewriting: false
-> invalid

I believe Case 1 should be the default.

Would you agree?
--- END REPLY ---

Thanks,

Jan

> Jörg
> [Message sent by forum member 'joma_javanet' (joma_javanet)]
>
> http://forums.java.net/jive/thread.jspa?messageID=328483
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jan Luehe

On 01/27/09 15:55, Jan Luehe wrote:
> Hi Joerg,
>
> On 01/27/09 13:37, glassfish@javadesktop.org wrote:
>> Hi Jan!
>> Read your answer carefully and agree to your argument that two
>> properties are redundant - only IF glassfish should support EITHER
>> cookies OR URL Rewriting.
>> But in my opinion glassfish could and should support BOTH behaviors
>> in parallel as well as let the dev opt for either or. My case is a
>> current webapp where some client browsers MAY deny cookies while
>> others will accept them.
>> Currently I cant serve both clients but rather have to decide A) to
>> choose the common denominator - url rewriting - which works for both
>> client browsers OR B) work with cookies and deny service to
>> not-accepting clients, telling them to enable cookies.
>>
>> I did not dig into the specs for j2ee server session tracking
>> behavior but otherwise stated i do not see a reason why "BOTH
>> behaviors in parallel" should not be possible. A hint to this,
>> contrary to your opinion, is that currently TWO properties are
>> specified in session manager properties. On the other side i do
>> wonder why since nearly one year nobody has objected, or at least
>> unit-tested, what i am suspecting, to be a bug.
>>
>
> Thanks for bringing this up!
>
> I just had an email exchange with Paul Carter-Brown (cc'ed) regarding
> this very topic.
>
> This is what Paul wrote:
>
>> Hi,
>>
>> I changed the setting and it now works without cookies. My
>> assumptions were correct however in that if I enable cookies on the
>> browser, the server still rewrites URL's. Personally I think that the
>> way it was before was much better in that the server effectively
>> assumes the worst case (there is no cookie support) and rewrites the
>> first URL and sets a cookie. If a request has a cookie, then it would
>> no longer rewrite the urls. This is the way all other web containers
>> do it so I dont see why Glassfish should be any different. The link
>> you attached shows that the initial problem people had could have
>> been erradicated by turning off URL rewriting in their setups as
>> opposed to regressing the default setup.
>
> ... and this is how I replied:
>
> --- BEGIN REPLY ---
> The link mentioned that people were concerned about the security
> implications of exposing
> a jsessionid inside a URL when they were not expecting the URL to be
> rewritten (since their
> webapp was declared to support cookies, via "enableCookies" set to
> "true").
>
> In the case referred to by the link, people did not want the
> jsessionid to be encoded in the URL.
> They were under the impression that by setting "enableCookies" to
> "true", their concerns
> would be addressed.
>
> There was no way for them to express that they wanted to disable URL
> rewriting other than
> by setting "enableCookies" to "true" (since "enableURLRewriting" was
> being ignored at the time
> the issue was filed).
>
> Now that I think about it, maybe "enableURLRewriting" should be a
> property in its own right,
> and it should be possible to set both "enableCookies" and
> "enableURLRewriting" to true at the
> same time. The way I just fixed
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=4394
> ("server log message says enableURLRewriting is not supported") in
> GlassFish v3 is to treat
> this as an error case, but maybe that's too restrictive.
>
> Perhaps both properties should be supported, with these semantics:
>
> Case 1:
> enableCookies: true
> enableURLRewriting: true
> -> jsessionid of new session stored in cookie *and* encoded in URL
>
> Case 2:
> enableCookies: true
> enableURLRewriting: false
> -> jsessionid of new session only stored in cookie (and not encoded in
> URL)
>
> Case 3:
> enableCookies: false
> enableURLRewriting: true
> -> jsessionid of new session only encoded in URL (and not stored in
> cookie)
>
> Case 4:
> enableCookies: false
> enableURLRewriting: false
> -> invalid
>
> I believe Case 1 should be the default.

I meant "Case 3" should be the default.

Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jan Luehe

On 01/27/09 16:04, Jan Luehe wrote:
> On 01/27/09 15:55, Jan Luehe wrote:
>> Hi Joerg,
>>
>> On 01/27/09 13:37, glassfish@javadesktop.org wrote:
>>> Hi Jan!
>>> Read your answer carefully and agree to your argument that two
>>> properties are redundant - only IF glassfish should support EITHER
>>> cookies OR URL Rewriting.
>>> But in my opinion glassfish could and should support BOTH behaviors
>>> in parallel as well as let the dev opt for either or. My case is a
>>> current webapp where some client browsers MAY deny cookies while
>>> others will accept them.
>>> Currently I cant serve both clients but rather have to decide A) to
>>> choose the common denominator - url rewriting - which works for both
>>> client browsers OR B) work with cookies and deny service to
>>> not-accepting clients, telling them to enable cookies.
>>>
>>> I did not dig into the specs for j2ee server session tracking
>>> behavior but otherwise stated i do not see a reason why "BOTH
>>> behaviors in parallel" should not be possible. A hint to this,
>>> contrary to your opinion, is that currently TWO properties are
>>> specified in session manager properties. On the other side i do
>>> wonder why since nearly one year nobody has objected, or at least
>>> unit-tested, what i am suspecting, to be a bug.
>>>
>>
>> Thanks for bringing this up!
>>
>> I just had an email exchange with Paul Carter-Brown (cc'ed) regarding
>> this very topic.
>>
>> This is what Paul wrote:
>>
>>> Hi,
>>>
>>> I changed the setting and it now works without cookies. My
>>> assumptions were correct however in that if I enable cookies on the
>>> browser, the server still rewrites URL's. Personally I think that
>>> the way it was before was much better in that the server effectively
>>> assumes the worst case (there is no cookie support) and rewrites the
>>> first URL and sets a cookie. If a request has a cookie, then it
>>> would no longer rewrite the urls. This is the way all other web
>>> containers do it so I dont see why Glassfish should be any
>>> different. The link you attached shows that the initial problem
>>> people had could have been erradicated by turning off URL rewriting
>>> in their setups as opposed to regressing the default setup.
>>
>> ... and this is how I replied:
>>
>> --- BEGIN REPLY ---
>> The link mentioned that people were concerned about the security
>> implications of exposing
>> a jsessionid inside a URL when they were not expecting the URL to be
>> rewritten (since their
>> webapp was declared to support cookies, via "enableCookies" set to
>> "true").
>>
>> In the case referred to by the link, people did not want the
>> jsessionid to be encoded in the URL.
>> They were under the impression that by setting "enableCookies" to
>> "true", their concerns
>> would be addressed.
>>
>> There was no way for them to express that they wanted to disable URL
>> rewriting other than
>> by setting "enableCookies" to "true" (since "enableURLRewriting" was
>> being ignored at the time
>> the issue was filed).
>>
>> Now that I think about it, maybe "enableURLRewriting" should be a
>> property in its own right,
>> and it should be possible to set both "enableCookies" and
>> "enableURLRewriting" to true at the
>> same time. The way I just fixed
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=4394
>> ("server log message says enableURLRewriting is not supported") in
>> GlassFish v3 is to treat
>> this as an error case, but maybe that's too restrictive.
>>
>> Perhaps both properties should be supported, with these semantics:
>>
>> Case 1:
>> enableCookies: true
>> enableURLRewriting: true
>> -> jsessionid of new session stored in cookie *and* encoded in URL
>>
>> Case 2:
>> enableCookies: true
>> enableURLRewriting: false
>> -> jsessionid of new session only stored in cookie (and not encoded
>> in URL)
>>
>> Case 3:
>> enableCookies: false
>> enableURLRewriting: true
>> -> jsessionid of new session only encoded in URL (and not stored in
>> cookie)
>>
>> Case 4:
>> enableCookies: false
>> enableURLRewriting: false
>> -> invalid
>>
>> I believe Case 1 should be the default.
>
> I meant "Case 3" should be the default.
>

Actually, I am having second thoughts about what the default behaviour
should be.

The default has always been to enable cookies
(enableCookies=true). There was no separate property for
"enableURLRewriting" (actually, there was one, but it was always
ignored).

Prior to the fix for

https://glassfish.dev.java.net/issues/show_bug.cgi?id=3972
("HttpServletResponse.encodeURL() unconditionally appends jsessionid
if session is newly created")

the jsessionid of a newly created session would be stored both as a
cookie and encoded in the URL, regardless of the value of
"enableCookies".

After the fix for IT 3972, it would be stored as a cookie (and not encoded
in the URL) only if enableCookies=true, and encoded in the URL (but not
stored as a cookie) if enableCookies=false.

Now that I've added support for "enableURLRewriting", I would like for
the default behaviour to be enableCookies=true and
enableURLRewriting=true. This way, both types of browsers (those that
support cookies and those that don't) will be supported out-of-the-box.

This setting would restore the original default behaviour (prior to
the fix for IT 3972), but would break the behaviour introduced by the fix
for IT 3972. However, those who want to enable cookies and disable URL
rewriting will now be able to do so by setting enableURLRewriting to
false.

Therefore, Case 1 will be the default in GlassFish v3.

I've also updated the GlassFish impl of the new
javax.servlet.SessionTrackingMode
feature introduced by the Servlet 3.0 spec to no longer treat the
presence of both
SessionTrackingMode.COOKIE and SessionTrackingMode.URL as an error.

Let me know what you think.

Thanks,

Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

bouteill
Offline
Joined: 2004-07-02

Hi Jan, thank you for following up! I unfortunately did not get an email notification from your posts and was unaware of them until just now (guess daily digest setting is not working).
Anyway, this is a burning SEO issue for us and I'd love a jar patch!
We're currently using Sun Java System Application Server 9.1_01 (build b09d-fcs)
My email is cyril{at}travelmuse.com
Thank you very much.

jluehe
Offline
Joined: 2004-12-01

hi cyril, i've attached an unofficial path that works with Sun Java System Application Server 9.1_01 (build b09d-fcs) to https://glassfish.dev.java.net/issues/show_bug.cgi?id=3972

bouteill
Offline
Joined: 2004-07-02

thank you very much!!!

bouteill
Offline
Joined: 2004-07-02

Could any developer from the glassfish dev team please give us some insight on how to configure url rewriting in v2?

jluehe
Offline
Joined: 2004-12-01

This is a bug in GlassFish.

Currently, the impl of HttpServletResponse.encodeURL() suppresses adding a jsessionid to its url argument only if the corresponding session was resumed from a cookie, but it does not consider the case where the session was newly generated. In the latter case, the jsessionid will be appended to the url argument unconditionally, even if the webapp supports cookies (meaning the newly generated jsessionid has already been added to the response as a cookie).

The diffs below (generated against the GlassFish V2U1 codebase) should fix the issue. Let me know if you prefer that I send you the patch in form of a class file (inside a JAR) instead, so you can test it.

In the meantime, I am going to file a bug in the GlassFish issue tracker.

Following are the diffs:

Index: CoyoteResponse.java
===================================================================
RCS file: /cvs/glassfish/appserv-webtier/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
retrieving revision 1.22.8.1
diff -u -r1.22.8.1 CoyoteResponse.java
--- CoyoteResponse.java 30 Oct 2007 00:17:09 -0000 1.22.8.1
+++ CoyoteResponse.java 5 Jan 2008 00:29:27 -0000
@@ -1486,8 +1486,10 @@
final Session session = hreq.getSessionInternal(false);
if (session == null)
return (false);
- if (hreq.isRequestedSessionIdFromCookie())
+ if (hreq.isRequestedSessionIdFromCookie() ||
+ (getContext() != null && getContext().getCookies())) {
return (false);
+ }

if (SecurityUtil.isPackageProtectionEnabled()) {
return ((Boolean)

Thanks,

Jan

whartung
Offline
Joined: 2003-06-13

Ah HA!

I've seen this behavior, but I just worked around it. I get jsessionid's appearing early on in the conversation, but eventually things settle down and they go away. The caused quite the bedlam when my security code didn't take in to account the jsessionid being on the URL.

I've since worked around it, but it will be nice when this gets rolled in to the release.

jluehe
Offline
Joined: 2004-12-01

I've submitted https://glassfish.dev.java.net/issues/show_bug.cgi?id=3972 ("HttpServletResponse.encodeURL() unconditionally appends jsessionid if session is newly created") for this issue, and I'm planning to commit the fix to the upcoming GlassFish v2.1 release.

jluehe
Offline
Joined: 2004-12-01

Fix committed.

whartung
Offline
Joined: 2003-06-13

Sweet, thank you!

oilagan
Offline
Joined: 2007-12-07

Hey there.

This is ironic. I have the exact opposite of your problem. Even though I have deployed my apps with sun-web.xml having the ff content:

I cant get HttpServletResponse.encodeURL() to produce a URL with jsessionid on it, even though I could before in SJS Appserver Platform Edition 9.0.