-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Add OAuth application flow for builtin mobile app #15541
Conversation
f17ce22
to
0b5ef1d
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.
The general direction is looking fine functionality and code wise. I like that the PR applies the structure of services/contracts to this part of the application as well.
Apart from what I noted down next to the code, documenting the feature is a necessity.
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.
Hey @oliverguenther thank you for this great and long awaited feature.
Disclaimer: I didn't check the code out. I simply read over the code changes.
One important thing that seems to be missing is the handling for existing tokens after the application got deactivated. I guess you have two options:
- have some sort of danger zone before the deactivation and tell the admin that this will delete all existing tokens. That is rather cheap to implement.
- check every API request, if the access token belongs to an OAuth application that is not deactive. That is expensive and probably not worth the effort.
Further, from the product perspective I see that client pretty generic and not mobile restricted. Thus I proposed a couple of changes (application name, redirect URI, ID).
While we are at it: Ideally we should tell client developers to implement "PKCE" to pretect the client from being intercepted by another app registering for the same redirect URI protocol. However, that is not in the responsibility of the OAuth provider, thus not strictly part of this PR.
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'll just reiterate @wielinde comments about security and overall approach.
0b5ef1d
to
9bc91f4
Compare
6cf1427
to
f65f697
Compare
f65f697
to
44f21ee
Compare
3a4b40d
to
820c4ab
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.
That's a ton. Code looks sane for the intended purposes.
c40f870
to
cf4c7c3
Compare
https://community.openproject.org/work_packages/53620