Saved password can prevent workstation registration

[Anna Goben]

Evergreen 3.2
Chrome

We've had an issue come up where a library saved their generic circulation account credentials in the browser. The workstation registration was deleted by accident, and no level admin account could override the saved profile to register a new workstation. The saved account had to be logged out of first as it overwrote the overriding account info. This does not happen when a low level account is logged into first, so it seems to be tied to the saving of the credentials.

[Terran McCanna (tmccanna)]

Interesting - clearing the cookies for the domain didn't clear out the saved credentials?

[Anna Goben (agoben)]

They managed to wipe out the workstation by syncing their Chrome login. And I think you can clear cookies/cache without touching the passwords if you configure the wipe correctly.

[Jeff Godin (jgodin)]

Anna-

Do you have steps that you can share to reproduce this?

Thanks!

-jeff

[Anna Goben (agoben)]

Yes, I was able to repeat the process again this morning on a local machine as follows:

1.) Save username and password of non-admin account in my Google Chrome account.
2.) Wipe the history of the browser, clearing the workstation registration. By default in Chrome, this does not clear out saved passwords.
3.) Attempt to use the client again with stored username.
4.) Shunted to workstation registration, which pops up the Permission Denied error/override entry when filled out.
5.) Enter admin credentials into the override box.
6.) Override fails and Permission Denied error reappears.
7.) Log out of Evergreen, strip the saved username/password, enter the admin account, and it works.

If the username/password of the non-admin account is used initially, but not saved in the browser, entering the admin override works as expected, forcing the registration.

[Meg Stroup (mstroup)]

I reproduced it here (accidentally . . .) when we moved to 3.3.3 this morning. I also noticed that a seemingly random number appeared in the upper right-hand corner (where you would normally see user @ workstation name).

The steps 4-6 Anna describes are a loop: you can try to force it as many times as you wish, but you'll be unable to register the workstation.

A few other SCLENDS libraries also reported this same issue this morning. When I ran into it, I just cleared everything in Chrome and re-registered. That was actually somewhat cathartic, if not the best solution.

The better solution: a sys admin in another county got around it by choosing "clear history" for Chrome and leaving "Cookies and Other Site Data" unchecked. After that, he was able to login without having to re-register the workstation. At least one other SCLENDS county used this workaround successfully.

[Jeff Godin (jgodin)]

Meg-

Can you provide steps to reproduce, or is that not possible due to the "accidental" part of your comment?

-jeff

[Remington Steed (rjs7)]

Meg,

That sounds like a different situation from the one Anna described in this bug ticket. We've seen your situation also since we upgraded to 3.3.1. We were able to restore the workstation by clearing only the browser cache, just like your sys admin did.

For the record, the cause of our problem (and presumably yours as well) was that the upgrade involved a change to the IDL. If the browser's cached version of the IDL doesn't match the version on the server, it can cause the data fields to not line up (for example, the web client showing a user ID where you expect to see a username). This was enough to convince the client that we didn't have a registered workstation. However, after clearing the cache (and thus fetching the latest IDL), our existing workstation was recognized without having to re-register.

[Terran McCanna (tmccanna)]

I've been unable to replicate this problem and it sounds like much of it was due to caching issues, so I'm inclined to mark it Won't Fix, but I'd like to know if anyone else has seen this issue on any recent version of Evergreen.