- User logs in, goes to the AngularJS Z39.50 search page, and does a search
- User leaves the Z39.50 tab open, maybe does other stuff
- Some time later, the AngularJS user session checker detects that the user session has expired, then invokes open-ils.auth.session.delete to remove it
- Ordinarily, this would redirect all tabs to the login page.
- Instead, for an as yet unknown reason, the following happens:
1. The Z3950SearchCtrl starts getting invoked repeatedly, spamming the following requests:
2. At the same time, something repeatedly invokes $scope.search() directly or a grid refresh, causing the Z39.50 search to be done repeatedly
A full page refresh does not appear to be happening, as otherwise the original Z39.50 search's parameters would not be retained. Also, a full page refresh would result in PCRUD queries of vibtg, which are not evidenced in the logs.
As it happens, the Z3950SearchCtrl initialization is occurring twice as there is both a route configuration and an ng-controller defined (via ctx.page_ctrl). Removing ctx.page_ctrl from Open-ILS/var/templates/staff/cat/z3950/index.tt2 removes the double-initialization. However, double-init is not the same as infinitely-looped init, so this may be a red herring.
So... some sort of infinite digest loop?
Also, open-ils.search.z3950.search_class lacks a direct permissions check. instead letting native-evergreen-catalog searches through regardless of whether the user is logged in. It does check permissions before performing searches for remote Z39.50 targets. However, as a mitigation it would be overall better if REMOTE_Z3950_SEARCH were checked at the top level.
I've traced a path how this happens:
- User logs in, goes to the AngularJS Z39.50 search page, and does a search auth.session. delete to remove it
- User leaves the Z39.50 tab open, maybe does other stuff
- Some time later, the AngularJS user session checker detects that the user session has expired, then invokes open-ils.
- Ordinarily, this would redirect all tabs to the login page.
- Instead, for an as yet unknown reason, the following happens:
1. The Z3950SearchCtrl starts getting invoked repeatedly, spamming the following requests:
open-ils.search open-ils. search. z3950.retrieve_ services null pcrud.search. cbs.atomic null, {"id":{"!=":null}}, {}
open-ils.pcrud open-ils.
2. At the same time, something repeatedly invokes $scope.search() directly or a grid refresh, causing the Z39.50 search to be done repeatedly
A full page refresh does not appear to be happening, as otherwise the original Z39.50 search's parameters would not be retained. Also, a full page refresh would result in PCRUD queries of vibtg, which are not evidenced in the logs.
As it happens, the Z3950SearchCtrl initialization is occurring twice as there is both a route configuration and an ng-controller defined (via ctx.page_ctrl). Removing ctx.page_ctrl from Open-ILS/ var/templates/ staff/cat/ z3950/index. tt2 removes the double- initialization. However, double-init is not the same as infinitely-looped init, so this may be a red herring.
So... some sort of infinite digest loop?
Also, open-ils. search. z3950.search_ class lacks a direct permissions check. instead letting native- evergreen- catalog searches through regardless of whether the user is logged in. It does check permissions before performing searches for remote Z39.50 targets. However, as a mitigation it would be overall better if REMOTE_Z3950_SEARCH were checked at the top level.