-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Add OAuth support to generic host provider #1062
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
Fix a bug in a view model property for the basic credentials prompt; we should be updating the backing field and also raising the PropertyChanged event.
567a0a8
to
36ad480
Compare
Context.Trace, | ||
config.UseAuthHeader); | ||
|
||
string refreshService = remoteUri.AbsoluteUri.TrimEnd('/') + "/refresh_token"; |
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 know there are some concerns about how we generate a service name for the refresh tokens with collisions with other credentials.
@hickford, you had suggested in the past using a subdomain to differentiate ATs and RTs:
https://foo.example.com/path/repo
https://refresh_token.foo.example.com/path/repo
Did you or @ldennington have any other suggestions? I was going to change to the refresh_token
subdomain example above if there was no objections.
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'm fine with the subdomain implementation.
Right now there's no facility to 'test' an existing OAuth credential is valid, so we rely on the less-than-optimal flow of Git trying, failing, telling us to erase, and then expect the user to retry and then we'll use the refresh token. In the future we may wish to allow a 'validity' endpoint to be configured where the generic implementation can make a GET request with the bearer token, and use the HTTP status code as a signal for validity (200 = OK, 401/403 => invalid). |
36ad480
to
d6521ba
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.
This is awesome!! 🚀
@@ -128,6 +128,33 @@ private async Task<ICredential> GetOAuthAccessToken(Uri remoteUri, string userNa | |||
Context.Trace, | |||
config.UseAuthHeader); | |||
|
|||
// |
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.
Nit: Is this line needed?
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've used this pattern in other places in the code base to visually make a block of explanatory comments standout more.
src/shared/Git-Credential-Manager.UI.Avalonia/Views/OAuthView.axaml.cs
Outdated
Show resolved
Hide resolved
Teach the Generic host provider to read configuration for OAuth-based authentication. These are largely parameters required for the OAuth2Client to be constructed including Client ID/Secret, Redirect URI and Scopes.
Add OAuth support for the generic provider offering browser (authcode grant) and device code (device auth grant) support. Device code and mode selection is initially only offered for TTY users.
Add support for storing and using OAuth refresh tokens. Prepend "refresh_token" as a subdomain to give better chances of avoiding a name clash compared with appending "/refresh_token" to the path component.
Add shared view models and commands for the OAuth GUI prompts. Two new commands and VMs are added, one for the initial 'mode' selection, and another to display the device code.
Add AvaloniaUI based implementations of the OAuth and Device Code generic UI prompts.
Add the WPF based GUI implementation of the OAuth and device code generic prompts.
Add detection and use of GUI prompts for OAuth authentication.
d6521ba
to
d8aa30b
Compare
Duplicate of #789 |
Add ability to provide OAuth-based authentication for generic hosts by way of simple Git configuration.
When a remote URL does not match any known host provider plugin, the generic provider will now first check for OAuth configuration in the Git config or environment variables. If such config is available then we try and perform OAuth authentication. Support for device code flow is optional, and refresh tokens will be used if the service supports and returns them.
Users can make use of existing Git config
include
to easily organise and share custom OAuth configurations:~/.gitconfig
example.ini
Fixes #1047