Rhythmyx seems to require cookies be enabled (presumably to store the JSESSIONID used by most server-side Java application servers.) But it doesn’t tell users that they need to enable cookies, it just fails to log them in. At least that is my experience testing so far. We have other issues that cause the log in to fail in the exact same way, so it would be good to rule out lack of cookies as a cause every time a user complains to us that they cannot log in. Before I log a support call, has anyone had any experience to the contrary? Or has anyone hacked a method to give users a friendly message? Alternatively, is this going to be solved in Rhythmyx 6.6 (either displaying a message, or making the system work without cookies with that aid of URL encoding?)
Yes, that is my experience. I should have made this clearer in my original post. Can anyone suggest a way to have it display something like “Authentication failed. Cookies must be enabled in your web browser preferences” just as it displays “Authentication failed. Invalid User Name and/or Password” when you misstype your password?
This also happens when the web browser’s cookie for the Rhythmyx server domain contain multiple JSESSIONIDs. Not sure how this happens - I cannot replicate it myself - but it occurs occasionally for some of our users, and when it does the lack of any error message explaining why they cannot login is pretty poor from a usability standpoint.
This is now a problem for our users. The following is a typical scenario:
[ol]
[li]The first time they use Rhythmyx, they go to the URL we have given them, which is http://ourserver/Rhythmyx (we use port 80 instead of the default 9992)
[/li][li]Because we have set up, using instructions sent by Percussion technical support, forced secure log in via HTTPS, they are automatically redirected to https://ourserver/Rhythmyx/login?sys_redirect=http%3A%2F%2Fourserver%2FRhythmyx%2F using a “302 Moved Temporarily” HTTP response. This reponse also sets a JSESSIONID cookie.
[/li][li]They bookmark this URL in their web browser
[/li][li]They log in and all is well until…
[/li][li]They come back another day by selecting the bookmark they previously created
[/li][li]The HTTP response sets a JSESSIONID cookie as in (2) but, as this is performed over HTTPS, the cookie is flagged as “secure” by their browser
[/li][li]They enter their username and password and click the Login button
[/li][li]They are authenticated (in our case via LDAP) and their JSESSIONID is presumably at this point flagged on the server-side as an approved session. They are automatically redirected to http://ourserver/Rhythmyx using a “302 Moved Temporarily” HTTP response. But the approved JESSIONID cookie that would allow this to proceed to the Content Explorer cannot be accessed by the code that is run on the server side in response to the request for http://ourserver/Rhythmyx because it was flagged as “secure” and http://ourserver/Rhythmyx is normal HTTP, not HTTPS.
[/li][li]Because of this, they are redirected back to https://ourserver/Rhythmyx/login?sys_redirect=http%3A%2F%2Fourserver%2FRhythmyx%2F using a “302 Moved Temporarily” HTTP response which also creates a new cookie, this time non-secure. No error message is displayed, the user is just presented with the login form again.
[/li][li]They think they have mistyped their password or something, and try again. But now there are two JSESSIONID cookies. Both of which can be read by the server when the connection is via HTTPS. But the secure one is already associated with an approved session on the server-side, so it presumably ignores the insecure JSESSIONID cookie, uses the secure one, and redirects them to http://ourserver/Rhythmyx. Again, the code that responds to that cannot access the secure cookie, and only sees the insecure and unapproved one. They are redirected back to the log in page. However many times the user correctly enters their username and password, this cycle will repeat.
[/li][li]At this point the user either: /li Gives up and swears off ever trying this horrible Rhythmyx thing ever again, or
(b) Calls us up to tell us our fancy new CMS is rubbish, and how dare we waste their time with it. We have to explain that they must close down all their web browser windows (to delete the two cookies), restart the browser, and type http://ourserver/Rhythmyx into their browser’s address bar.
[/ol]
The same thing happens when one user emails another user the URL of the login page, copied and pasted from their browser’s address bar. Or if they pick the “wrong” URL when their browser gives them an autosuggest list of possible URLs after typing the start of the server name.