Cannot login to web staff client if work station does not exist in database
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Evergreen Version: 2.7+
OpenSRF version: 2.4 (but doesn't apply)
Postgres version: Doesn't matter
If you have registered a workstation with the web staff client that subsequently disappears from the database, you cannot login via the web staff client until after you have cleared the workstation entries from local storage in the browser. This is not likely to come up in production environments, but could easily arise in training or demo situations where the database is refreshed periodically.
To reproduce this bug,
Login with the web staff client.
Register a new workstation from the Administration menu.
Logout and log back in to see that the registration is working.
Logout of the web staff client.
In PgAdmin or some other database tool, delete the entry from actor.workstation for the workstation that you registered above.
When you next try to login with the web staff client, the login will fail.
The osrfsys.log will have entries like the following for each failed login attempt:
open-ils.auth 2015-06-22 15:40:02 [INFO:30482:
Creating new event: WORKSTATION_
If you clear the workstation information from your browser's local storage for the domain where you are using the web staff client, you will be able to login again, but you will need to register your workstation again.
The above also assumes that you have only registered 1 workstation. If you've registered multiple workstations, you can still login with any that exist in the database.
Changed in evergreen: | |
assignee: | nobody → Victoria Lewis (vlewis-q) |
Changed in evergreen: | |
assignee: | Victoria Lewis (vlewis-q) → nobody |
Changed in evergreen: | |
status: | New → Confirmed |
Changed in evergreen: | |
assignee: | nobody → Jennifer Pringle (jpringle-u) |
Changed in evergreen: | |
assignee: | Jennifer Pringle (jpringle-u) → nobody |
Changed in evergreen: | |
milestone: | 2.next → 2.12-beta |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
The XUL client would remove the workstation from the local config, log the user in, then present the user with the workstation registration interface. The browser client does not require a workstation, so after we clean up the bogus WS, we'll have more options to consider.
The simplest work flow for now might be:
* Login fails with WORKSTATION_ NOT_FOUND .default" and "eg.workstation .all" via Hatch API workstation/ index) or 2) continue without a workstation.
* Delete the bogus WS from "eg.workstation
* Log the user in without a workstation
* Show a dialog to the user explaining that the workstation does not exist then offer two options: 1) go to the workstation admin page (admin/
Related to this, I've been considering whether we should add a toggle for "this computer requires a registered workstation", similar to the existing "This workstation uses a remote print / storage service" toggle. That would of course change the proposed work flow.