-
Notifications
You must be signed in to change notification settings - Fork 896
feat: add OAuth2 applications #11197
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
Conversation
0706a37
to
2bdd363
Compare
These are applications that will be able to use OAuth2 to get an API key from Coder.
These let you add, update, and remove OAuth2 applications.
d865c7f
to
1ff12c8
Compare
1ff12c8
to
430140e
Compare
Not sure about the race tests...will look into it later. |
Github allows any user to make an Oauth2 app. Do we expect this to be the case for Coder? Do we want Coder to not allow personal Oauth2 apps, and only allow global oauth apps? Should apps be scoped to an org? |
coderd/database/dbauthz/dbauthz.go
Outdated
func (q *querier) InsertOAuth2AppSecret(ctx context.Context, arg database.InsertOAuth2AppSecretParams) (database.OAuth2AppSecret, error) { | ||
if err := q.authorizeContext(ctx, rbac.ActionCreate, rbac.ResourceOAuth2AppSecret); err != nil { | ||
return database.OAuth2AppSecret{}, err | ||
} | ||
return q.db.InsertOAuth2AppSecret(ctx, arg) | ||
} |
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.
We should incorporate this in the encrypted db layer.
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.
TypeScript looks good! There's a lot of files, though, so I'll do a second review pass later today to check the stories and pull the repo down to kick the tires a bit
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/CreateOAuth2AppPage.tsx
Outdated
Show resolved
Hide resolved
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/CreateOAuth2AppPage.tsx
Outdated
Show resolved
Hide resolved
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/EditOAuth2AppPageView.tsx
Outdated
Show resolved
Hide resolved
</TableHead> | ||
<TableBody> | ||
{isLoadingSecrets && <TableLoader />} | ||
{!isLoadingSecrets && (!secrets || secrets?.length === 0) && ( |
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.
Could the second case be simplified down to !secrets?.length
? I think that would catch both the undefined and 0 cases
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.
It definitely could, for some reason I like to always compare length
to a number rather than make use of falsey checks.
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.
Honestly, that's generally what I default to, too – I guess my main concern here was making sure the condition isn't too long, since there's not an easy way to name it without moving the value all the way above the return statement
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/EditOAuth2AppPageView.tsx
Show resolved
Hide resolved
event.preventDefault(); | ||
const formData = new FormData(event.target as HTMLFormElement); | ||
onSubmit({ | ||
name: formData.get("name") as string, |
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.
I get that the type assertions are necessary to exclude the File
type, but do you think we should still have null
checks?
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.
Honestly I should probably use Formik or whatever, and add the validations too. I just...dislike Formik haha
I figure null
will be caught by validation, either on the frontend (if I add it) or the backend. But from a code complete perspective it does seem like adding null
here is the right move.
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.
Since the page is blocked from being used outside of development for now I am going to punt frontend validation for another PR, if that seems chill.
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/OAuth2AppsSettingsPageView.stories.tsx
Outdated
Show resolved
Hide resolved
I asked and looks like we should be scoping them to an org for the future, and right now owner-only is fine (so I think we should leave the possibility this will change). |
Also remove a ? since that condition would short-circuit if `secrets` was not set. We could just do a falsey check, but I like to compare length to a number.
I think this is right?
This is to make sure it is not mistaken as the actual secret.
Moved them to the queries directory and they all invalidate now.
The endpoints are disabled until we can implement the token exchange.
@@ -315,6 +333,15 @@ export const AppRouter: FC = () => { | |||
path="external-auth" | |||
element={<ExternalAuthSettingsPage />} | |||
/> | |||
|
|||
<Route path="oauth2-provider"> | |||
<Route path="apps"> |
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.
One thing I noticed during testing: I think there should be a redirect or something when the user tries to go go the deployment/oauth2-provider/
URL path
Right now, it doesn't take you to a completely empty screen, but you only see the navbar and the Deployment options
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.
I am hesitant to do that because one day we might have something else on that page (like for example a toggle for whether to enable the oauth2 provider) and I would not want folks getting confused learning they can go to just /oauth2-provider
to get to the apps, if that makes sense.
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.
That said, seems like it should at least show a proper 404. Mine gives this error:
"user" must be an existing uuid or username.
queried user="deployment"
So I guess it is falling through to some other page.
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.
Whoops I was on dev.coder.com
, yeah you are right it shows a blank page with the deployment sidebar. That is pretty weird. Is there even a way for me to show a 404 here? Maybe a redirect is the only fix...
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.
I added a route with NotFoundPage
.
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.
Ah but that is weird too because the sidebar is still there. At least the page says "not found" I guess.
I'll get a green checkmark on this today. We should get this in soon to prevent merge conflicts on the moving base. |
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/OAuth2AppsSettingsPageView.tsx
Outdated
Show resolved
Hide resolved
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/EditOAuth2AppPageView.tsx
Show resolved
Hide resolved
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.
The UI worked really well when I was testing things out. Just had a few more comments
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/EditOAuth2AppPageView.tsx
Outdated
Show resolved
Hide resolved
site/src/pages/DeploySettingsPage/OAuth2AppsSettingsPage/EditOAuth2AppPageView.tsx
Outdated
Show resolved
Hide resolved
This will work better on smaller screens. Also I had an extra useless Stack around the button.
- Make it a header - Add a copy icon
One day we might have other settings on this page but for now there is nothing to show.
This should not normally be possible because the modal would prevent hitting the delete button but you never know.
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.
Lets get this in.
665808e
to
bd8cab4
Compare
This is part 1 of #11084.
It adds the oauth application configuration part. The actual token exchange is not implemented yet, probably will use
golang/oauth2
. As a consequence I have not linked the new page in the sidebar, but it can be accessed by going to/deployment/oauth2-apps
. The endpoints are restricted to dev.This is big enough that I felt like it made sense to get a review on it now even though the token exchange is missing. It is just a bunch of CRUD, so mostly tedious work like queries and a frontend for those queries.
Two areas in particular I am not sure about:
Did I do the RBAC part right?I am not actually preventing adding/editing applications but maybe I should? I was going to prevent the token exchange though.I am doing this now.Relying on backend validation right now but maybe should do it on the frontend since the backend errors are a bit hard to read. Also could add that emoji picker to the icon field.