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