Comment 4 for bug 1861013

Jeff, given your response in comment #3, it makes sense to me that this is done in JavaScript.

I think there needs to be a major change to how this works: The patron's password should not be cached until after their OPAC login is successful. This way, we avoid caching a typo. Doing this in JavaScript in the browser is a great deal more complicated than doing it in the back end code. The browser would need to store the plaintext password somewhere (a cookie?) while the back end does it's thing, and then cache it when the login is successful. I suppose it could cache the password when the login form is submitted, and then remove it from the cache if the login fails.

Then, there is the issue of the cache call failing.

There's also the question of having a separate Ebook API session. Is this of any use if the patron is not logged into the OPAC, yet? If no, then why have it all? The relevant data could be added as keys on the patron's OPAC session. If yes, then OK, perhaps we need better code to retrieve one that already exists when a patron logs into the OPAC. (Your comment makes it sound like that isn't possible from the back end at least.) Maybe a cookie will work here?