-
Notifications
You must be signed in to change notification settings - Fork 43
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
Creating providers with config #3334
Conversation
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.
✅ No Invisible Unicode Characters Detected.
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.
✅ No Invisible Unicode Characters Detected.
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.
✅ No Mixed Scripts Detected.
return nil, fmt.Errorf("error getting provider config: %w", err) | ||
} | ||
|
||
// This method feels like it should be part of the class manager? |
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.
Yes, it probably should :) ... but I would not block on it.
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.
✅ No Invisible Unicode Characters Detected.
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.
✅ No Mixed Scripts Detected.
No longer a draft. Even after splitting some patches out, this is still a relatively large PR. I would welcome ideas on how to split it. |
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
// Package session contains the business logic for creating providers from session state. |
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.
Thought: I wonder if we should move other session state logic in here in future. (not a blocker for 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.
👍🏻
return g.ghService.GetConfig(ctx, class, userConfig) | ||
} | ||
|
||
func fallbackOAuthClientConfigValues(provider string, cfg *server.OAuthClientConfig) { |
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.
Could we do this config-reading logic once at application startup?
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.
done
@dmjb ready for another review |
…iderTracker In order to be able to add the providerAuthManager in the next step and avoid code duplication, let's make the providerClassManager a little more reusable by extracting the code that tracks registered classes.
Adds the providerAuthManager interface that exposes per-provider OAuth settings. This allows the provider creation in an OAuth callback to let the provider specific code sit in the provider codebase and let the creation be provider agnostic. ALso creates a sessionService that currently allows to create a provider from a session record that is created before the OAuth conversation. Fixes: mindersec#3263
Adds the CLI support for creating an OAuth provider with a config.
Two or more, use a for.
Allows to pass provider configuration when creating a GH app. This will be useful for creating providers with repository auto-enrollment. Fixes: mindersec#3263 Unlike the OAuth flow which is reusable for any provider, the GH App flow is quite GH-app specific and thus uses the original GH app handler.
We added a ProviderConfig-based structure but then in a subsequent patch we overwrite its values unconditionally. Let's only overwrite them when set.
Based on review feedback, to isolate the fallback code.
Summary
This would create a provider with custom configuration.
The OAuth code is generic and can be used by any provider. The GH App config code is very GH App specific, but that whole flow is unlikely to be reusable, so I think that's fine.
With github you can enroll either with oauth:
or:
Change Type
Testing
see above
Review Checklist: