Comment 5 for bug 1861013

I'm not sure what problem we solve by waiting for successful OPAC login before caching the password. The open-ils.ebook_api.patron.cache_password call will overwrite any existing cached password for the current EbookAPI session, so if there's a typo, the cache should be updated with the correct value when the user re-enters their password correctly. Currently, if the patron enters a bad password, at worst we send off a bad auth request to Overdrive, which fails; if they subsequently enter the correct password, there is a subsequent Overdrive auth request, which succeeds -- or at least it would succeed if password caching was working.

We need an EbookAPI session prior to OPAC login because you can't look up title and availability info without obtaining a client access token from the API, and the EbookAPI session is where that token is stored by Evergreen. The session is created and managed by the server, not the browser, in order to avoid exposing the library's client key, secret, etc. to the end user during the client access request. We use that same EbookAPI session for password caching and patron auth related stuff (checkouts, holds, etc.) because it keeps things simple, and because other APIs might not be as good as Overdrive at making a clean distinction between "client" and "patron" authorization.