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.
We already added running users, but we didn't handle removing users from the proxy
if the user's server was stopped (e.g. while the Hub was restarting).
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)
This is the first small part of easing the pain of services,
which is generating the API tokens,
and used to require initializing the JupyterHub database.
- Otherwise does not work with MySQL
- Change JSONDict to be TEXT (Unbounded) rather than VARCHAR.
This makes most sense, since you can't index these anyway.
- The 'ip' field in Server is set to 255, since that is the
max allowed length of DNS entries.
- Most of the rest of the Unicodes have approximately high
values that most people should not mostly run into
(famous last words).
check_routes checks for missing routes for running users.
This is meant for when the proxy has been relaunched outside the Hub.
If spawners are slow to start, it's possible for check_routes to fire in the middle of spawning,
triggering addition of the user's server (which has no defined location yet) to the proxy before it's up.
If the spawning fails, the route will remain indefinitely (because it never should have been added in the first place), and the user will see 503 until their server is launched manually again.
Checking `spawn_pending` in user.running prevents this.
relies on CHP's host-based routing (a feature I didn't add!)
requires wildcard DNS and wildcard SSL for a proper setup
still lots to workout and cleanup in terms of cookies and where to use host, domain, path, but it works locally.
in check_routes, it has been reported that users without a running server are attempted to be added.
So something is wrong, either in sqlalchemy or my understanding of what it does (likely the latter),
because a filter for users with a non-None server is returning at least one result whose server is None.
This is to resolve the 'Network is Unreachable' error experienced by a few when JupyterHUB is connecting to localhost.
On most recent linux OS versions like CentOS 6, 7, Red Hat 6, 7, Oracle Linux 6, 7, etc, the hosts file (/etc/hosts) usually has a line to make the server IPv6-ready:
::1 localhost
even if the given server actually has no IPv6 permissioned. In such case the Python socket library when connecting to 'localhost' will try to connect via the IPv6 protocol - which will fail with the 'Network is Unreachable' error.
To solve this we capture this error and try to reconnect on 127.0.0.1 instead of localhost, alias forcing the user of the IPv4 protocol.
allows setup/cleanup to be performed by the authenticator
use this to open PAM sessions at spawn
and close them at stop,
rather than open at login and never close.
Server started, but never became accessible:
> Failed to reach your server.
> Please try again later.
> Contact admin if the issue persists.
Server failed to start (errors in Spawner):
> Failed to start your server.
> Please contact admin.
