IsSession on auth token and validate admin creds on setup

[neelvirdy]

Along with application-research/estuary-www#164, fixes application-research/estuary-www#99 and #815

1. Adds IsSession field on AuthToken table and populates with false for tokens created via api admin page, and true for logins/signups. Session tokens will not be rendered in the api admin page so users cannot mix up their service and session tokens. The frontend will also no longer support authenticating via API key to prevent using a service token as a session token. That feature is also unnecessary when admin login is fixed.
2. When running ./estuary setup, validates admin username and password to be compatible with bcrypt's requirement of 1-32 alphanumeric characters on usernames and 8+ alphanumeric characters on passwords.

I got a success with a valid creds, but omitted it from the screenshot.

[en0ma]

@neelvirdy how did you come up with the term session token for the admin API key?

[en0ma]

Session tokens will not be rendered in the api admin page so users cannot mix up their service and session tokens

Makes sense, since it's a one-time setup key (session?) no need to show it in the UI. My question now is, does this mean the admin after logging in will have to then create a service API key if they need a key?

[en0ma]

When running ./estuary setup, validates admin username and password to be compatible with bcrypt's requirement of 1-32 alphanumeric characters on usernames and 8+ alphanumeric characters on passwords.

Would this play nicely with already existing credentials?

[neelvirdy]

@neelvirdy how did you come up with the term session token for the admin API key?

The session field actually doesn't correspond to admin vs regular user. It's purely whether or not the token was generated through login/signup, or if it was a manually provisioned key. In otherwords, session tokens will live in browser cookies exclusively. Service tokens are for all other use cases exclusively (scripts, curls, and other services calling estuary).

The admin creds are relevant to this change because admin login on estuary-www was not working, which forced us to authenticate via API key instead. But, authenticating via API key introduces a risk of mixing up session vs service tokens which defeats some of the purpose of the distinction. This is why the linked estuary-www PR fixes the admin login in addition to making the change to not render session tokens.

Session tokens will not be rendered in the api admin page so users cannot mix up their service and session tokens

Makes sense, since it's a one-time setup key (session?) no need to show it in the UI. My question now is, does this mean the admin after logging in will have to then create a service API key if they need a key?

Login creates a key, so the admin will get their first key simply by logging in with the credentials they ran ./estuary setup with.

When running ./estuary setup, validates admin username and password to be compatible with bcrypt's requirement of 1-32 alphanumeric characters on usernames and 8+ alphanumeric characters on passwords.

Would this play nicely with already existing credentials?

Bcrypt already throws an error if these requirements are not met, we are simply catching it earlier so the user can't create a user in DB with invalid credentials, only to get a login failure down the road.

[en0ma]

LGTM

[en0ma]

LGTM

[alvin-reyes]

LGTM