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
problem.
I found the reason for this problem. But don’t know the correct solution.
The reason is that RT’s runs from the /rt subdirectory on this server.
That subdirectory is where the authenticated session cookie applies.
When Webkit browser asks for /favicon.ico that is above the /rt
directory, therefore the login cookie is inapplicable there. So, RT
sends back a response with a new cookie.
The reason this happens on 1 of my servers and not the other is
because RT on the broken server is one of many NameBasedVirtualHosts.
So if the visitor is at this hostname, it hits RT, even if /rt was not
part of the REQUEST_URI. On my other server, it uses mod_vhost_alias
for all the domains, and RT is installed just as an Alias /rt. So on
that server when /favicon.ico is requested, the answer does not come
back from RT, but from one of the other mod_vhost_alias domains
because the Alias does not apply.
It seems I need some kind of rewrite rule in the Apache config to
handle people asking for “/file” instead of “/rt/file”
Or maybe just remove the “Alias /rt
/usr/share/request-tracker3.8/html” and other references to /rt in the
Apache configs and just let RT run at DocumentRoot instead of in a
subdirectory?
Anyone else running RT in a subdirectory of a NameBasedVirtualhost
with a suggestion?
…says that the conventional method doesn’t work in 3.6 and above.
I’ve created Custom Fields for ‘tickets’, added it to the queue, and when
I create a new ticket the dropdown box is there.
But in both simple and advanced saarch I’m unable to make RT find results
based on the option (development categories 'bugs, ‘feature requests’,
etc) that was chosen for the custom field.
For future readers, to make it so that requests for objects above the
$WebPath directory (like /favicon.ico, when WebPath is “/rt”) do not
trash the current session, I changed the RT installation so that it
runs from the root directory of a subdiomain (rt.example.com) instead
of a subdirectory (example.com/rt).
…says that the conventional method doesn’t work in 3.6 and above.
I’ve created Custom Fields for ‘tickets’, added it to the queue, and when
I create a new ticket the dropdown box is there.
But in both simple and advanced saarch I’m unable to make RT find results
based on the option (development categories 'bugs, ‘feature requests’,
etc) that was chosen for the custom field.
…says that the conventional method doesn’t work in 3.6 and above.
I’ve created Custom Fields for ‘tickets’, added it to the queue, and when
I create a new ticket the dropdown box is there.
But in both simple and advanced saarch I’m unable to make RT find results
based on the option (development categories 'bugs, ‘feature requests’,
etc) that was chosen for the custom field.