Disappearing RT session causes search refresh to fail


[I’m not sure if this would have been more appropriate for rt-users rather than rt-devel, but I figured it involves RT internals so hopefully this list is appropriate]

We recently upgraded from an ancient 3.8.17 to 4.2.5. The upgrade all seemed
to go smoothly and our staff are using the new RT without any problems …
all except for one user who uses KDE’s konqueror as their browser.

That user has set up a search and requested that the search be refreshed
every 2 minutes. Under RT3 this worked fine. With RT4 they find that after
a random period, the refresh stops working. If I run konquorer I am able to
replicate this behaviour.

As detailed below this appears to be related to the associated session
disappearing from the rt4.sessions table.

We do run a slightly odd setup, using WebRemoteUserAuth with a homegrown
apache authentication mechanism, so maybe the problem is related to that?
Having said that, our system has worked for years without problems with
RT3 and seems to work fine for RT4 and many other web applications we use.
But because of it I’m not necessarily expecting others to be able to point to
exactly what is going wrong. Rather, any suggestions as to further debugging
to help figure out what is going on will be appreciated.

Further details follow for those still interested…

The number of successful refreshes before the failure seems to vary (typically
only 1 or 2 but can be more). When the refresh fails an empty page is returned
with the header “Find tickets”. The dropdown at the end has reverted back to
"Don’t refresh this page". The attached screenshot shows this.

I noticed that the refresh is done differently in RT4 than RT3, with a cross
site request forgery token being passed in the URL for each refresh.

When the refresh works, I can do the following database query:

mysql> select id, LastUpdated from sessions where a_session like “%af48ae37a2efa40c7aa4acdef3f04d2c%”;
| id | LastUpdated |
| d4470653e0e912de74948f80c3372694 | 2014-09-29 11:15:00 |
1 row in set (0.45 sec)

(The bit between the “%…%” is the CSRF_Token value for this refreshed

When the search refresh fails, if I repeat the above query the session with
the above id no longer exists.

As you can see from the screenshot, the browser is still reporting “Logged
in as …”.

There has been no interaction with the RT between the last refresh that worked
and the one that didn’t.

So my first question is, does anyone have any idea what might be going on

Failing that, can anyone provide pointers to help me understand how RT
sessions work (presumably they set a session cookie that the browser sends
back with each request) and what might make one disappear.

We’re definitely not running rt-clean-sessions.

I’ve just noticed that we do have WebExternalAuthContinuous turned on in
RT4 whereas we had it turned off for RT3. I don’t see how our authentication
scheme could have done a “logout”, but if those who know think that is the only
way that an RT session would get removed I will investigate that possibility.


When the refresh fails an empty page is returned with the header “Find
tickets”. The dropdown at the end has reverted back to “Don’t refresh
this page”. The attached screenshot shows this.

Whoops. Here it is.