-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IsSession on auth token and validate admin creds on setup #861
IsSession on auth token and validate admin creds on setup #861
Conversation
37c7eff
to
f928c3d
Compare
7f1055a
to
06b18ef
Compare
@neelvirdy how did you come up with the term |
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? |
Would this play nicely with already existing credentials? |
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.
Login creates a key, so the admin will get their first key simply by logging in with the credentials they ran
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. |
31ae6e8
to
4ef1996
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
e6130a2
to
4ef1996
Compare
1dca5bb
to
8accb2c
Compare
c34eeff
to
f56257f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Along with application-research/estuary-www#164, fixes application-research/estuary-www#99 and #815
IsSession
field on AuthToken table and populates withfalse
for tokens created via api admin page, andtrue
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../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.