Comments (11)
Some way to say "look at this envvar" from the config file would be a good way to do this. I guess making the password be something like:
token = "string" # current status
token = { value = "string" } # what it is interpreted as
token = { environment = "variable" }
This would also be possible:
token = { process = [ ... ] }
Guidance from rust-lang/rfcs#2730 would be useful to know how to interpret the process
case on different platforms.
from cistern.
I'm not fond of changing the configuration file just to get tokens from environment variables because it seems like a very narrow use case. It also encourages sharing the same token with multiple applications which is not ideal.
However the token-from-process
used by cargo
seems like a good idea since it should cover most use cases of people storing their secrets outside of the configuration file. I'm not too worried about cross platform compatibility since Golang provides exec.Command
to run arbitrary commands and the signature of this function matches the value expected for token-from-process
.
So setting a token could be done in a couple of ways:
# Token stored in the configuration file
token = "mytoken"
# Token stored in an environment variable
token-from-process = ["bash", "-c", "echo $MY_API_TOKEN"]
# Generic case: token returned by calling `executable arg1 arg2 ...`
token-from-process = ["executable", "arg1", "arg2"]
As mentioned in the RFC the process inherits stdin
and stderr
so people could store their tokens in their password manager and be prompted for a password when running cistern
. It seems like a good solution. Thanks @mathstuf for pointing out the RFC.
from cistern.
It also encourages sharing the same token with multiple applications which is not ideal.
This is the exact use case I have. I don't want to generate 15 tokens for GitHub but have on per machine and share it with all my programs and using ENVs for something is not narrow. Basically any program which wants an API Token of some sort uses the ENV GITHUB_TOKEN
.
Also I don't really see the need to store an API token which has the scope of showing publicly available information in a password manager.
from cistern.
Why would you need a token per project for cistern
? Isn't the token per host in the configuration file?
from cistern.
I made the changes for this feature on the following branch: https://github.com/nbedos/cistern/tree/feature/token_from_process
Usage is detailed in the sample configuration file:
# Also, every "token" key can be replaced by "token-from-process" which is a list of strings
# consisting of the name of an executable to call followed by the arguments to be provided to it.
# The process will inherit stdin and stderr (allowing for password prompts) and the output of the
# process will be used as the value of the token.
#
# Examples:
# # Read token from environment variable
# token-from-process = ["bash", "-c", "echo $MY_API_TOKEN"]
#
# # Read token from `pass` store
# token-from-process = ["pass", "ci/gitlab/cistern"]
#
I tested this with pass and the workflow is quite nice. You get a single password prompt and then cistern
starts as normal. It even works without an X server.
@SuperSandro2000 Let me know what you think.
from cistern.
Single password prompt even for multiple tokens?
I still kinda prefer getting environment variables directly.
from cistern.
Well you can do that by setting token-from-process = ["bash", "-c", "echo $MY_API_TOKEN"]
and you won't be asked for a password.
pass
is just a password store I tested but you don't have to use it all. But yes, it asks for a single password if all tokens are encrypted using the same GPG key.
from cistern.
This only works if I have the tokens in my startup script and is kinda a workaround.
Using os.Getenv("MY_API_TOKEN")
would be preferable and just nicer.
from cistern.
This only works if I have the tokens in my startup script
This should be fixed by a4392aa
Using
os.Getenv("MY_API_TOKEN")
would be preferable and just nicer.
Yeah but then I have to implement, test and document both token-from-env
and token-from-process
when just the second configuration option covers both cases.
I understand the syntax is not ideal but it provides the functionality you requested and I don't see any other drawback. And given how it's implemented it will also work for other people storing their credentials elsewhere meaning it's unlikely I'll have to extend this feature later.
from cistern.
Yeah but then I have to implement, test and document both
token-from-env
andtoken-from-process
when just the second configuration option covers both cases.
So right now we are both lazy and don't want to do something. I mean it should be fine. Thanks 👍
from cistern.
So right now we are both lazy and don't want to do something.
Just stop contributing to this repository. I'm sure you can find other repositories and developers that are up to your standards.
from cistern.
Related Issues (20)
- Support refreshing the view HOT 16
- Support sorting by column HOT 7
- Add support for Azure Pipelines HOT 2
- Perform actions on jobs and pipelines HOT 1
- Support for private gitlab instance HOT 7
- help `?` blows up on osx HOT 1
- Collapse subtrees on success HOT 10
- cistern working on windows HOT 1
- unknown repository url with GitLab ssh access HOT 8
- GitLab API privileges HOT 2
- Follow logs HOT 2
- cistern exits on network failure HOT 1
- Occasional fails with circleci HOT 6
- Azure builds not showing on PR branches HOT 4
- LICENSE file is executable in packages
- Without BROWSER set, cistern exits
- Expand git urls using `git remote get-url` HOT 4
- Look up BROWSER in PATH HOT 3
- Send alerts to the terminal on events HOT 1
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 cistern.