Skip to main content

[webtier] Re: How to prevent Glassfish v2 to rewrite urls with jsessionid?

6 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
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: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-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: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-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: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

Lincoln Baxter, III

Hey JSFers,

I'm getting an odd exception when running JSF2.0 on Tomcat 6, and a
pretty simple page.

When passing in a null value, in Development stage mode, JSF tries to
get a logger at line 123, but throws the below exception:
What could this mean?

Thanks!

@Override
public Object put(String key, Object value) {
Util.notNull("key", key);
HttpSession session = getSession(true);
Object result = session.getAttribute(key);
if (ProjectStage.Development.equals(stage) && !(value instanceof
Serializable)) {
LOGGER.log(Level.WARNING,

"jsf.context.extcontext.sessionmap.nonserializable",
new Object[]{key, value.getClass().getName()});
}
//noinspection NonSerializableObjectBoundToHttpSession
session.setAttribute(key, value);
return (result);
}

Caused by: com.ocpsoft.pretty.PrettyException: PrettyFaces: Exception
occurred while processing
java.lang.NullPointerException
at com.ocpsoft.pretty.beans.ActionExecutor.executeActions(Unknown
Source)
at com.ocpsoft.pretty.event.PrettyPhaseListener.beforePhase(Unknown
Source)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:207)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)
at
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310)
... 105 more
Caused by: javax.el.ELException: java.lang.NullPointerException
at org.apache.el.parser.AstValue.invoke(AstValue.java:176)
at
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at com.ocpsoft.pretty.util.FacesElUtils.invokeMethod(Unknown Source)
... 112 more
Caused by: java.lang.NullPointerException
at com.sun.faces.context.SessionMap.put(SessionMap.java:123)
at com.sun.faces.context.SessionMap.put(SessionMap.java:57)
at
com.ocpsoft.storylib.jsf.FacesUtils.setSessionAttribute(FacesUtils.java:97)
at com.ocpsoft.storylib.pages.login.LoginBean.load(LoginBean.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.el.parser.AstValue.invoke(AstValue.java:172)
... 114 more
[att1.html]

Ryan Lubke

Lincoln Baxter, III wrote:
> Hey JSFers,
>
> I'm getting an odd exception when running JSF2.0 on Tomcat 6, and a
> pretty simple page.
>
>
> When passing in a *null value*, in Development stage mode, JSF tries
> to get a logger at line 123, but throws the below exception:
> What could this mean?
Fixed this yesterday. Grab last night's nightly build.
>
> Thanks!
>
> @Override
> public Object put(String key, *Object value*) {
> Util.notNull("key", key);
> HttpSession session = getSession(true);
> Object result = session.getAttribute(key);
> if (ProjectStage.Development.equals(stage) && !(*value
> instanceof Serializable*)) {
> LOGGER.log(Level.WARNING,
>
> "jsf.context.extcontext.sessionmap.nonserializable",
> new Object[]{key, value.getClass().getName()});
> }
> //noinspection NonSerializableObjectBoundToHttpSession
> session.setAttribute(key, value);
> return (result);
> }
>
>
>
> Caused by: com.ocpsoft.pretty.PrettyException: PrettyFaces: Exception
> occurred while processing
> java.lang.NullPointerException
> at com.ocpsoft.pretty.beans.ActionExecutor.executeActions(Unknown Source)
> at com.ocpsoft.pretty.event.PrettyPhaseListener.beforePhase(Unknown
> Source)
> at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:207)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
> at
> com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310)
> ... 105 more
> Caused by: javax.el.ELException: java.lang.NullPointerException
> at org.apache.el.parser.AstValue.invoke(AstValue.java:176)
> at
> org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
> at com.ocpsoft.pretty.util.FacesElUtils.invokeMethod(Unknown Source)
> ... 112 more
> Caused by: java.lang.NullPointerException
> at com.sun.faces.context.SessionMap.put(SessionMap.java:123)
> at com.sun.faces.context.SessionMap.put(SessionMap.java:57)
> at
> com.ocpsoft.storylib.jsf.FacesUtils.setSessionAttribute(FacesUtils.java:97)
> at com.ocpsoft.storylib.pages.login.LoginBean.load(LoginBean.java:58)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.el.parser.AstValue.invoke(AstValue.java:172)
> ... 114 more

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

lincolnbaxter
Offline
Joined: 2008-03-26
Points: 0

You are the man. I'll give it a shot, thanks.