Remove authenticate via API key since it's unnecessary now that admin login is fixed, and to prevent mixing up session and service tokens
Warning: if any estuary node operators have an admin user with a password that doesn't meet the 8 alphanumeric characters bcrypt requirement, they will end up getting locked out of that user when that token expires. They can create a new estuary admin by re-running setup but there may still be files tied to the original admin user. Alternatively, they can hit the change password endpoint while they have a valid token for that user and change it to a valid password.
New login screen (checkbox is unchecked by default):
Note: I'm also open to not having a checkbox and just attempting the admin login on any auth failure.
No keys will be rendered if users haven't made any service tokens explicitly:
Expected user pattern is to label your service tokens clearly here and they will be the only tokens present:
I can no longer authenticate into estuary-www with that service token, so there's no risk of mixing up that token with my session. This removes the risk of signing out with a service token in your cookie and accidentally revoking it, which would break your service's integration with estuary.
Blocked on https://github.com/application-research/estuary/pull/861
Along with https://github.com/application-research/estuary/pull/861, fixes https://github.com/application-research/estuary-www/issues/99 and https://github.com/application-research/estuary/issues/815
Warning: if any estuary node operators have an admin user with a password that doesn't meet the 8 alphanumeric characters bcrypt requirement, they will end up getting locked out of that user when that token expires. They can create a new estuary admin by re-running setup but there may still be files tied to the original admin user. Alternatively, they can hit the change password endpoint while they have a valid token for that user and change it to a valid password.
New login screen (checkbox is unchecked by default):
Note: I'm also open to not having a checkbox and just attempting the admin login on any auth failure.
No keys will be rendered if users haven't made any service tokens explicitly:
Expected user pattern is to label your service tokens clearly here and they will be the only tokens present:
I can no longer authenticate into estuary-www with that service token, so there's no risk of mixing up that token with my session. This removes the risk of signing out with a service token in your cookie and accidentally revoking it, which would break your service's integration with estuary.