High Issue Summary
session.tokenkey value sometimes generated with quotes. This can impact the SSO experience by unexpectedly overwriting cookies
Environment
- Crowd 3.3.3
- Confluence any version
Steps to Reproduce
- Connect Confluence and Crowd with SSO
- Login to Confluence as Crowd users
- Go to Browser Console, to check the session cookies generated
Expected Results
Session.tokenkey (or crowd.token_key) value will not have quotes
Actual Results
Session.tokenkey (or crowd.token_key) values will have quotes when an equal(=) sign exist in the token
Looking into the HAR file, the token with quotes will have 1 pair of quotes being escaped that look something like this:
"name": "crowd.token_key", "value": "\"xxxxxxxxxxxxxxxxx=\"",
Notes
- This issue not seen without SSO
- This issue does not exists in Crowd version 3.2.5
Workaround
- As the Token is being generated randomly, the affected user can try to Log Out and re-Log In again to get a new token generated.
There are still chances that after re-logging the user still get another token with an equal(=) symbol in it and hitting into the same issue
- mentioned in
-
Page Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CWD-5352] session.tokenkey value randomly generated with quotes causing login issues to applications
using Crowd 3.1.2 over HTTPS, but I don't see above given token pattern in cookies. DO you know why is that? 
Confirming that 3.4.5 has resolved this issue for us - thanks for the fix team Crowd!
We have just upgraded from Crowd 3.3.0 to 3.4.4 and seem to have hit this issue as well
- We have two types of applications:
- Native Atlassian applications (jira/confluence/bitbucket/crowd/bamboo)
- PHP applications using either the Pear PHP Crowd library or the Wordpress Crowd addon
- The native apps can reliably SSO with each other
- The PHP apps can reliably SSO with each other
- When going from a native app to a PHP app (or vice versa) the SSO seems to conflict forcing the user to login to one app and then destroying the session from the other type of application
after upgrading Jira to 7.0.11 which use Tomcat 8.0.17, I can still see the double quotation marks in the cookie.
can cookie values consist of alphabets and numbers only? if so, the quotes may not be necessary. Please raise the priority higher, without the fix, it is impossible for customers to upgrade to crowd 3.4. SSO is a key feature for Crowd in my opinion. Thanks.
I would expect this to be probably Tomact related, since below Tomcat 8 they did quote every Cookie value, which has an "=" in it, with dquotes automatically - which is also the case here (base64 encoded i assume). So this might no even be application, but rather container related.
We ran into this issue with the 3rd Party Confluence Addon GoEDIT. The Addon was not able to authenticate anymore. 6000 users handicapped, no fun for the admins.
Thomas
Hershan, It seemed to depend on the length of the username . Our test show 21-chars don't generate an '=', but 20-chars long does, 19-chars does.
I think from memory it went something like NO, NO, YES for 19,20,21 as a username length and repeats that pattern.