privy is used for encryption
- db only has blob column, no knowledge of encryption
- add CryptKeeper for handling encryption
- use privy for encryption, so we have fewer choices to make
- storing/loading encrypted auth_state runs in a ThreadPool
- MultFernet allows key rotation via `AUTH_STATE_KEY=secret2;secret1;secret0`
- Failure to decrypt results in cleared state
- Attempting to set auth_state without encryption is a hard failure
- Absent encryption, auth_state will always be None
for easier re-use of login in custom handlers
Further, enable auto_login + no custom login handler to mean that auth info is already present in requests
(e.g. REMOTE_USER)
- remove use of deprecated Hub.server
- add deprecation warning to Hub.server property
- move cookie_name declaration to Hub
It should now be possible to use Hub.from_url('http://1.2.3.4:1234/hub/') without missing information
Lots of custom proxy implementations that are distributed are
eventually consistent, and it might take upto a few seconds for
all the components to start redirecting properly. If we do
exponential backoff when doing these redirects, it gives the
proxies a lot of time to catch up. We also explicitly raise an
error if it's going on too long, instead of giving the user
juts a 'redirected too many times' error.
flag for waiting for the proxy to be updated
avoids User.running being True when the user's server has not yet been added to the proxy,
causing potential redirect loops.
OAuth access tokens can only be used to identify users, not perform actions on their behalf, which API tokens do.
Implementing OAuth scopes would allow us to achieve this limitation without separating the two items, but that would be a much bigger change, including having an OAuth "Would you like to grant permissions..." confirmation page.
- OAuth access tokens *are* APITokens.
oauth_access_tokens table only stores extra oauth metadata.
- only store hashed client_secret in database,
using HashedCompare to allow comparison.
.spawn_pending used for the *whole* window, from request to responsive (added to proxy)
.waiting_for_response is just used for the window between Spawner.start returning (process started, http endpoint known) and http endpoint becoming responsive
.waiting_for_response will never be True while .spawn_pending is False
service_tokens supersedes api_tokens,
since they now map to a new services collection,
rather than regular Hub usernames.
Services in the ORM have:
- API tokens
- servers (multiple, can be 0)
- pid (0 if not managed)
should avoid needing to cram user-detection / intent into other endpoints.
That functionality isn't removed,
but warnings are added indicating that /user-redirect/ should be used instead.
