-
-
Notifications
You must be signed in to change notification settings - Fork 105
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
Read token from other sources (like secret/password manager) #382
Comments
Defs support this, and even like the way you suggest using a different (alt) creds key. This way there aren't any backwards compatible issues. One thing we'll need to sort out is the current first time flow which has users create a token and enter directly into lab, which then writes the config. This might be fine, as users who want this can just delete the raw token and place into password managers a accordingly. |
Xpost from #402
- Me
- @prarit This approach seems reasonable as well, provided we're confident we can reliably detect token vs command. I suppose this could be as simple as taking the token and trying a gitlab call (like GetUser) or the inverse, attempting to execute and seeing checking for failure. |
IMHO it's better to be explicit than clever --- adding a different key (at least in the beginning) is guaranteed to not cause compatibility issues. Eventually the alternative token behaviour can be merged back into the current In any case, given #406, #407, and #151, is this worth pursuing now or waiting for the dust to settle somewhat? |
We can pursue this now, this should fit in well with the other stuff. |
@tfurf , I'm waiting on the dust from #414 to settle but this feature will nicely fit into the new config work.
|
I'm trying to think of a test to write for load_token. The only thing I can think of doing is creating a simple bash script dummy_token.sh
and creating a dummy lab config with
and executing 'lab mr list' in the test repo to see if lab read in the token or not. |
@tfurf , can you checkout #416 and test please? As stated above, I've added a "load_token" config option that will use the contents of "load_token" as an executable, and use that output as the token value. For example, Please provide your testing input in #416 . Thanks :) |
Having the user token stored in plaintext makes the config file not a great candidate for being version controlled. Is there some appetite or view forward on being able to load the tokens dynamically from somewhere else?
For example, I use
pass
, [1], and normally to load a password I would do something like:In the config, this might be something like,
This relates to #151, #155 , etc.
The text was updated successfully, but these errors were encountered: