I have noticed that my Ubuntu install of RT 3.8.4 (but not my Debian
install of same) gives Chrome and Safari browsers a new session cookie
whenever they click an Attachment
(/rt/Attachment/[transactionId]/[attachmentId]/filename). So after a
logged-in user views an attachment, the cookie they have no longer
matches up with the one they were using to be considered logged-in.
Then any subsequent action results in a login prompt.
The logout problem does not happen when clicking any other links in
RT. Only the links to attachments kill the session.
I checked the MySQL session table to see what happened to the old
session and it is still there. I don;t know why RT issues a new one.
The a_session field is a longblob. I truncated the sessions table and
started again, but still the same. The same behavior occurs both
whether session is stored in MySQL or in ‘Apache::Session::File’ (with
RT Config for WebSessionClass).
I have watched my network with Wireshark and see that when Safari and
Chrome ask for the Attachment, the GET request includes the Cookie
header with the correct (logged in) cookie. The server response
returns the attachment without any cookie header, and then webkit
immediately asks to GET /favicon.ico, without any cookie header.
That’s when the server replies back with a new cookie in a response
that contains the login page.
Firefox and Opera browsers don’t have any problem at all with losing
their session after clicking an attachment.
Here’s a little screencast that shows consistent session loss for
Safari and Chrome, only when clicking into an Attachment:
Any ideas on why this would happen? I have another Debian install of
3.8.4 that is almost identical to this Ubuntu one and don’t get this