[jgoguen]

I have almost everything I host at home set up behind SSO. Calibre, for valid reasons I don't want to interfere with, doesn't work well with this because it needs HTTP Basic/Digest auth. That needs the Authorization header, but there isn't a safe way to get the password (or any user-specific secret) to generate the Authorization header in the SSO auth flow. What I've done so far to let me keep SSO auth is disable calibre auth and allow unauthenticated local writes. Which I don't really like, but I am confident in my ability to adequately protect the running calibre instance, but if I can let the SSO auth flow tell calibre what the authenticated user is I could start thinking about allowing other SSO users access to calibre with reduced permissions.

Would it be acceptable to you to add a server flag to trust REMOTE_USER? Maybe with some additional check like you have to configure the front-end proxy to also send some kind of a 'X-Calibre-I-Know-What-I-Am-Doing: dogscholar' header with a static or configurable or generated value. The flow I see happening would be something like:

- A default-disabled checkbox in content server settings (corresponding to maybe --trust-http-remote-user for CLI use) has to be turned on, with a warning that misconfigured proxies could allow bypassing calibre auth
- When calibre processes a request, if REMOTE_USER (and the check header if wanted) is set it proceeds as if auth for that user was successful
- If the user isn't in the user DB, or if we want a check header and it's missing or wrong, calibre server should fatal with HTTP 403
- If REMOTE_USER is not set, request HTTP Basic/Digest auth as it does today

I don't want to interfere with the existing login process since I know calibre server needs to also work with non-browser clients. I think this lets us have both, the existing login process is available without interference and anyone who wants to set up auth using the front-end proxy's auth mechanism can also do so without blocking non-browser clients from also connecting. It's just a bit of extra work to have both proxy and non-browser auth since you'd have to manage credentials in both the proxy back-end and calibre user DB, but I feel like that's an acceptable trade-off. I also don't see this being used by a whole lot of people so I understand if you're OK with the idea but don't want to prioritize it. It won't be soon, but if something like this is acceptable to you I don't mind working on a PR to add it in once I sort out some nasty conversion bugs in my KePub plugins.