-
Notifications
You must be signed in to change notification settings - Fork 29
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
Embed default provider at compile time #29
Comments
Now that each provider has its own sub command I close this issue. Please reopen if you think this feature is still worth implementing. Thanks! |
Hi @dkerwin, i think it's important when you have to provide a custom build, for example in the case of dex integration. Whenever you provide a custom build to your end users, you should be able to alter the default provider so the cli command is as simple as possible. Right now it forces me to alter the code which is relatively trivial but would prefer to have a declarative approach. |
Hi @tlvenn! I understand your point. How would that look like now that providers are split into individual sub commands? Have a new subcommand (eg. default) that is just a wrapper around the compile time configured provider? |
Hi @dkerwin, I though google was still implicit ? If there is no implicit provider anymore, I think having some kind of fallback would be great, I don't really expect that |
It would be great if we can set the default provider during the compile time and still use simpler form of command |
@Filip-Havlicek my though exactly |
The problem I see here is that |
I think it's more about trying to keep it as simple / stupid as possible for end users. Maybe the official release of dexter should not favor one provider over another so effectively there is no fallback defined and the provider has to be explicit. And for custom build being released by orgs, they can define the fallback provider at compile time so that it's invisible to their users if they want to. It's the same reasoning for the a potential Dex integration and its endpoint which is by nature custom. I would rather tell people in my org to do: Of course the tradeoff being that now someone needs to build and distribute a custom build. Some orgs might choose the simpler approach on leveraging the official distribution and pushing the concern of oidc provider and its endpoint to their users and some org will choose the other path but I believe both should exist and be facilitated without forcing people to create a fork of the project and to maintain it. |
We are only using google, so we don't need other providers (at the moment). I understand why you reworked provider code. I just liked old behaviour when I simply wrote |
Thank you both for the clarifications. I'll have a closer look at the problem see if I can come up with a good solution. I'm glad dexter is helpful to you @Filip-Havlicek |
Hey @tlvenn & @Filip-Havlicek, would be great if you could give the PR a spin and see if it matches your expectations. |
@dkerwin I built it and it works as expected and it matches my expectations. You are fast. |
Awesome, that's perfect, thanks @dkerwin ! |
Right now, google is the default provider set in the code unless told otherwise with a cli flag. Just like we can embed credentials at compile time, it would be great to be able to set the default provider as well.
The text was updated successfully, but these errors were encountered: