Comments (14)
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 dexter auth default
could work but dexter auth
could / should fallback to a predefined provider that can be changed at compile time.
from dexter.
It would be great if we can set the default provider during the compile time and still use simpler form of command dexter auth
instead of new form dexter auth google
.
from dexter.
I think it's more about trying to keep it as simple / stupid as possible for end users.
If a given org is only going to use a single provider at a time, why should it forces its users to specify it all the time, it should be transparent / invisible.
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: dexter auth
rather than dexter auth dex https://dex.mycompany.com
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.
from dexter.
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
from dexter.
Hi @tlvenn! Is this issue still something you would want to have after #30 is merged?
from dexter.
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!
from dexter.
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.
from dexter.
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?
from dexter.
@Filip-Havlicek my though exactly
from dexter.
The problem I see here is that auth
would show unpredictable behaviour. If a provider is predefined, it would run that and if not it would just show the help screen. Wouldn't it be exactly as helpful to have a new command (eg. default, builtin, xxx)? Is the driver for the both of you to give your users a consistent experience even if you decide to switch providers?
from dexter.
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 dexter auth
.
New additional command for default provider doesn't make sense (for me). In that case, it's not problem use the real provider name (google in my case).
By the way, I like dexter and thanks for it.
from dexter.
Hey @tlvenn & @Filip-Havlicek,
would be great if you could give the PR a spin and see if it matches your expectations.
from dexter.
@dkerwin I built it and it works as expected and it matches my expectations. You are fast.
from dexter.
Awesome, that's perfect, thanks @dkerwin !
from dexter.
Related Issues (20)
- Add Microsoft Windows support
- Add tests
- Create docker image and publish it on the hub HOT 1
- Unable to start dexter HOT 2
- How to use generated credentials HOT 6
- Fix Travis CI release process HOT 1
- Support an option to kubeconfig output path HOT 1
- ID and Secret-id is still required even when the binary has been built with the said parameters HOT 11
- Create a dedicated sub-command per provider
- Wrong kube config path.
- Two different kube config users generated from one google user HOT 3
- Authenticate as Google Service Account HOT 5
- Using dexter with dex? HOT 2
- Race condition on http server teardown
- dexter OIDC vs SSL Cert Login HOT 2
- Missing tmpl/kube-config.yaml HOT 2
- OOB deprecation
- goreleaser warnings
- Timeout too low HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dexter.