Add OAuth application flow for builtin mobile app #15541
Conversation
oliverguenther
force-pushed
the
feature/53620/builtin-oauth-app-mobile
branch
from
d0b6a17
to
f17ce22
Compare
oliverguenther
force-pushed
the
feature/53620/builtin-oauth-app-mobile
branch
from
f17ce22
to
0b5ef1d
Compare
| redirect_uri: "openprojectapp://oauth-callback", | ||
| builtin: true, | ||
| confidential: false, | ||
| uid: "DgJZ7Rat23xHZbcq_nxPg5RUuxljonLCN7V7N7GoBAA" |
There was a problem hiding this comment.
💡 Since the UID is not secret it might help consumers to use something that is more readable, e.g. OpenProjectAppUID (and something more if filling is necessary)
| I18n.t(:button_activate), | ||
| toggle_oauth_application_path(application), | ||
| class: "oauth-application--edit-link icon icon-unlock", | ||
| method: :post |
There was a problem hiding this comment.
This leads to a link without icon which is unusual for the table:
AFAIK, the intend is to move away from link to button based actions completely but this might be for a different time.
There was a problem hiding this comment.
A somewhat unrelated question: Why not allow toggling the active status for all applications?
There was a problem hiding this comment.
Interesting idea. However, I struggle to find a use case for it. You either want an application or not. Such a toggle for not built-in application would only make sense if the associated tokens would also get toggled (and not deleted, which btw is missing in this PR). But I believe that is not worth the effort.
| end | ||
| end | ||
| end | ||
| end |
There was a problem hiding this comment.
This has no specs whatsoever. Since it is the piece of code guarding against invalid changes, having specs ensures everything is working as desired.
| end | ||
|
|
||
| def applicable? | ||
| Doorkeeper::Application.where(builtin: true).empty? |
There was a problem hiding this comment.
I believe we better use a criteria of the to be seeded application, e.g. its application ID rather than an attribute (so instead of where it would become a find_by. I can imagine a future where we have more builtin applications.
| .call( | ||
| enabled: true, | ||
| name: "OpenProject Mobile App", | ||
| redirect_uri: "openprojectapp://oauth-callback", |
There was a problem hiding this comment.
I guess that this OAuth application is a generic application. It's usage is not limited to a certain mobile app. I am thinking of other user apps, such as a CLI or Solibri integration. They would need exactly the same stuff but are no mobile app. That is why I propose a more generic name and callback URL protocol
| redirect_uri: "openprojectapp://oauth-callback", | |
| name: "OpenProject generic client (e.g mobile app)" | |
| redirect_uri: "openproject://oauth-callback", |
There was a problem hiding this comment.
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.
https://community.openproject.org/work_packages/53620