Pre-register OAuth2 applications for git credential helpers#26291
Conversation
|
Maybe we need to check the delete functions to don't allow delete OAuth2 Applications from both UI and API. |
|
@lunny done |
|
Actually, the "ClientID" can be any string if I understand correctly. If so, maybe it's even better to use "builtin-git-cred-oauth" / "builtin-git-cred-manager", it brings consistent user experience for the config too: And the pre-defined ClientIDs could avoid the database migration (no need to add the Locked field, just check the ClientID) |
|
If you don't mind, could I push some changes for idea #26291 (comment) ? |
|
@wxiaoguang Feel free to make any changes if you want |
Nope. But I am not sure whether allowing site admin editing the name/URL/confidential is good ... Personally I would agree more with hickford: allowing editing would confuse users. |
|
Even though I think there could be use cases for it, I'm fine with disallowing edits as the concerns are valid and changes to confidential/redirect URIs could break the whole functionality |
wxiaoguang
left a comment
There was a problem hiding this comment.
I think the client IDs could be written into the document, to make them could be found easily.
Done |
|
@denyskon please fix the merge conflicts. 🍵 |
* upstream/main: Pre-register OAuth2 applications for git credential helpers (go-gitea#26291) Make `user-content-* ` consistent with github (go-gitea#26388) Add pull request review request webhook event (go-gitea#26401) Introduce ctx.PathParamRaw to avoid incorrect unescaping (go-gitea#26392)
|
-> Avoid GCM OAuth2 attempt when OAuth2 is disabled #36000 |

This PR is an extended implementation of #25189 and builds upon the proposal by @hickford in #25653, utilizing some ideas proposed internally by @wxiaoguang.
Mainly, this PR consists of a mechanism to pre-register OAuth2 applications on startup, which can be enabled or disabled by modifying the
[oauth2].DEFAULT_APPLICATIONSparameter in app.ini. The OAuth2 applications registered this way are being marked as "locked" and neither be deleted nor edited over UI to prevent confusing/unexpected behavior. Instead, they're being removed if no longer enabled in config.The implemented mechanism can also be used to pre-register other OAuth2 applications in the future, if wanted.
Co-authored-by: hickford mirth.hickford@gmail.com
Co-authored-by: wxiaoguang wxiaoguang@gmail.com