Hi Peter,
sorry for the confusion: When you mentioned URL encoding, I assumed
you were referring to it as the session tracking mode that is used as an
alternative to cookies, but your latest response makes it clear that you are
talking about URL encoding of cookie values.
Let me investigate and get back to you.
Thanks,
Jan
On 01/26/10 12:13 PM, Major Péter wrote:
> Hi Jan,
>
> thanks for the quick reply, but it looks like, this isn't the issue.
> I red in a forum the following comment:
> "In Glassfish V3 prelude, after deploying opensso.war in domain1, the
> login does not succeed. The reason being, there is a issue with cookie
> encoding in GFV3.
>
> Workaround: Edit server.xml of web server instance or the domain.xml of
> glassfish, add the following jvm option, restart the container.
>
> <jvm-options>-Dcom.iplanet.am.cookie.c66Encode=true</jvm-options>"
>
> In my case, the opensso is deployed to a GFv2, and the protected
> application is on GFv3. (The policy agent isn't currently compatible
> with GFv3, but I'm trying to make it so..)
>
> So in theory the following happens, when I visit a protected page:
> The agent goes to SSO, to check, whether I have an active session or
> not, creates a session cookie on the SSO domain, then sends back the
> sessionId to the agent, which will create an another cookie for the
> application domain, but it looks like that the content of the GFv2
> cookie and the GFv3 cookie isn't the same (I can't really say what's the
> difference, because in the testsystem they are on the same domain (via
> apache+ajp)...)
>
> But when in the opensso I enable the following option:
> Encode Cookie Value:
> Specifies whether to URL encode the cookie value. (property name:
> com.iplanet.am.cookie.encode)
>
> Then everything works just fine.
> Our testsystem isn't that good, that we could check whether every single
> site works with this changed option, so we would like to change GFv3
> settings if it's possible.
> A sample session cookie value looks like this:
> AQIC5wM2LY4SfczUWdsBAOJE4kfV1cQdnVti7U1bS7osnOc=_at_AAJTSQACMDE=#
>
> Thanks,
> Peter
>
> 2010-01-26 03:53 keltezéssel, Jan Luehe írta:
>
>> Hi Peter,
>>
>> On 01/25/10 05:44 PM, Major Péter wrote:
>>
>>> Hi,
>>>
>>> Is it possible, that something changed in the cookie handling between
>>> GFv2 and v3? I'm experiencing some problems with my OpenSSO + Agent
>>> configurations, possibly because the cookies are in GFv3 now by default
>>> url-encoded. Is this true? If so, how can I disable this behaviour?
>>>
>>>
>> You mean "session ids" [as opposed to cookies] are in GFv3 now by default
>> url-encoded", right? :)
>>
>> Yes, this is a side-effect of the fix for:
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=4394
>>
>> See the comment I had added there:
>>
>> <comment>
>> Based on feedback received by the community, "enableURLRewriting"
>> needs to be supported as a property "in its own right", i.e., it must be
>> possible to set both "enableCookies" and "enableURLRewriting" to "true"
>> (or
>> "false") at the same time.
>>
>> paulcb_at_dev.java.net wrote:
>>
>> 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.
>>
>> See the thread at
>> http://forums.java.net/jive/thread.jspa?messageID=328588 for
>> additional details.
>>
>> By default, both "enableCookies" and "enableURLRewriting" will be
>> set to true.
>> </comment>
>>
>> Note that Servlet 3.0 adds standard support for configuring the
>> desired session tracking modes for your application. You can disable URL
>> rewriting either declaratively (in your web.xml), as follows:
>>
>> <web-app>
>> <session-config>
>> <tracking-mode>COOKIE</tracking-mode>
>> </session-config>
>> </web-app>
>>
>> OR programmatically (e.g., from a ServletContextListener), like this:
>>
>> servletContext.setSessionTrackingModes(EnumSet.of(
>> SessionTrackingMode.COOKIE));
>>
>> Hope this helps.
>>
>> Thanks,
>>
>>
>> Jan
>>
>>
>>> Thanks.
>>>
>>> Best Regards,
>>> Peter Major
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>