-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Preconfigure OAuth Git credential helpers #25653
Conversation
7b796b5
to
7d31a40
Compare
fe893d8
to
a1854e5
Compare
Tested, working |
a1854e5
to
bda8550
Compare
2080741
to
731c2ca
Compare
I'm not a fan of that approach, because even if the admin explicitly deletes that OAuth application, it reappears on restart. I don't think that's wanted behavior. How about the following idea:
|
Or we can have a configuration to enable/disable the feature. |
The problem as it seems to me is that our system of OAuth applications isn't made for preconfigured ones. If we make a configuration option for this, we'd have to decide how to handle if something changes manually, for example an admin deletes one of the predefined OAuth apps while keeping the configuration parameter. This would probably result in the same thing I described in my previous comment - deleted OAuth apps reappearing again. What we could do is creating another field for OAuth apps where we set whether they are visible are hidden in the UI. I still think the best way to do it though would be a checkbox on the installation page, and then we maybe could add a button in the OAuth apps UI to recreate those OAuth apps if they were deleted. |
I agree, that's unexpected.
I can't think why an admin would want to delete these Git credential helper OAuth apps (or later recreate them). If admin wants to disable HTTPS authentication, they can set existing configuration DISABLE_HTTP_GIT. Deleting the apps wouldn't actually block Git Credential Manager or git-credential-oauth, just break their default configuration, and force users to do manual configuration. To block them completely, admin would have to disable OAuth entirely with oauth.ENABLE = false. Security is strong -- Gitea requires individual users consent to authorize the apps on each authentication (assuming #25061) https://imgur.com/a/7RRUPES . The applications are registered with loopback redirect URI 127.0.0.1 , so unlike web apps, there's no risk of domain hijacking. They are public clients, not confidential clients, so there's no risk of secret leakage because they don't have secrets. |
731c2ca
to
98913f0
Compare
98913f0
to
97d30ec
Compare
I've added a config option to prevent the applications being recreated, though I can't think when this would be useful. |
if setting.OAuth2.GitCredentialHelpers { | ||
// the following Git credential helpers are universally useful | ||
// https://git-scm.com/doc/credential-helpers | ||
_ = db.Insert(ctx, []OAuth2Application{ |
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.
how about add a subcommand like ./gitea manager init-git-credential
to insert this record into db?
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_APPLICATIONS` parameter 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. ![grafik](https://github.com/go-gitea/gitea/assets/47871822/81a78b1c-4b68-40a7-9e99-c272ebb8f62e) 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> --------- Co-authored-by: M Hickford <mirth.hickford@gmail.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
OAuth Git credential helpers are universally useful so preregister on every instance. https://git-scm.com/doc/credential-helpers
Fixes #25189