Comment 17 for bug 1036318

To add a little to what Jason pasted and stated (thanks!) in comment 16:

There are two scenarios for symptoms here. The first is more common, and more closely matches the original reports in this bug:

In a staff client with at least one tab open to the TPAC catalog interface, all existing and new TPAC interfaces lose their login session, while other interfaces such as checkin / checkout / item status remain functional, and do not prompt the user to re-authenticate. The most common means of recovery here is logging out and then back into the staff client. At least one of the TPAC tabs will be at the default /eg/opac/home URL.

This is demonstrated well by the screencast included by Michele Morgan in comment 6, above: http://screencast.com/t/KZ2pb5EUWbl -- tabs 1 and 4 seem to have redirected to the TPAC "home" page.

This seems most likely to be caused by the following:

Given a default auth.staff_timeout value of 7200 seconds (2 hours), any TPAC page in the staff client includes a meta http-equiv refresh to the TPAC logout URL, timed for 7200 seconds. If you have a TPAC tab open in the background sitting idle, no matter what you're doing in other tabs, the idle tab eventually reaches the end of that 7200 second timer, and loads the TPAC logout page. This clears the cookies in the staff client, breaking any browser interfaces which rely on the cookie to authenticate (such as TPAC). The logout process clears the cookie, then redirects to the TPAC "home" page.

The fix: Don't include the refresh in TPAC when TPAC is being used within the staff client. This is a one-line template change, working branch located at user/jeff/lp1036318_opac_timeout_in_staff_client

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeff/lp1036318_opac_timeout_in_staff_client

The second scenario for symptoms is where both the TPAC and non-TPAC interfaces in the staff client stop working, and while the TPAC interface does not prompt the user to re-authenticate, the XUL interfaces do prompt to re-authenticate, and after successful re-authentication any new or existing TPAC tabs are once more logged in (after a reload or new page navigation in the case of existing TPAC tabs).

The second scenario seems most likely to be caused by early memcached eviction of the user's session -- OR a normal expiry of the user's session. Better handling of session expiry in TPAC, and increasing session durability in the face of memcached restarts or slab memory exhaustion might be distinct bugs.

Thanks to everyone who added thoughts to this bug, and thanks especially to Chris Sharp and Jason Stephenson for helping in confirming symptoms and testing fixes.

I'll open a new wishlist bug on the session durability issue.

Shall we also have a bug on enabling TPAC to re-authenticate after session timeout, or leave that issue as a part of this bug?

Either way, the change in the working branch mentioned above should stand on its own, and can be reviewed and signed off by any interested party -- Jason?