Is this a problem with cookie visibility? E.g. is the cookie being set either on another host or with a specific URL that it applies to? This might cause the browser to not send the cookie to Jforum.
It might also be related to various browser level security constraints. Many modern browsers don't allow for long term cookies by default. Some even deny short term session cookies if the security contraints aren't modified.
FWIW, the RequestContext object that gets passed to the SSO methods is really a "wrapped" HTTPServletRequest object. So if you need more information about the Java context, you can just re-cast this and get access to all the methods. E.g.:
I had trouble with SSO until I configured tomcat for session sharing through the SSO Valve. After that, I could see the session cookies from the other application. I posted a reference to it in this issue:
I see that you are using CookieSSO, so I am not sure if this applies.
Diego [originally posted on jforum.net by andune76]
... a mechanism that is 'better' in means that it could be widely used even though if jforum and other applications are not on the same server is the SSO mechanism via URL request parameters. It is necessary however to have a 'cipher' mechanism included to make sure that the parameters are 'encrypted' and that noone else can sneak in without permission.
Something that is hardly ever asked about for instance is:
You recieve emails when a new post is made. This email holds a link that allows oyu to jump straight to the entry on the forum. Have you yet tried this? Normally it should reject the access as the user is not logged in.
For this I had to write some mechanism so that the spammer would write the URL of the surrounding application, with a hook_url parameter that holds the jforum data. This is the url that the user will be redirected to straight after successful login. [originally posted on jforum.net by Sid]
You can't expect to wield supreme executive power just because