Disappearing RT session causes search refresh to fail
Duncan McEwan <[email protected]>
| Newsgroups | gmane.comp.bug-tracking.request-tracker.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, [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 search). 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 here? 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. Duncan -- RT Training - November 4-5 Los Angeles http://bestpractical.com/training