W dniu 30.05.2011 06:54, Michael Hudson-Doyle pisze:
Hi all,
$ lava-tool submit-job --farm https://mwhudson:%24token@validation.linaro.org test.json
This could then remember, bzr style, that it's is the farm you want to talk to. Unlike bzr the knowledge would be global (per user) so it would be stored in ~/.config/lava/... (unlike in git/bzr in some local directory).
This is clearly a bad idea though: tokens will be long and unwieldy and passing it on the command line means they will be disclosed in ways that we should avoid (they'll appear in ps output for all users and could easily end up in log files).
For a brief moment, yes. IMHO we should not care about this. If you want 'ps privacy' you can do that on a system wide level. If we really want we can supply some argument that will trigger /dev/tty interaction.
$ lava-tool submit-job --farm https://mwhudson@validation.linaro.org test.json --token Token for mwhudson@validation.linaro.org: ***********
So we need a way of storing tokens. The easiest thing to do would be to store a token for a (username, host) pair, so you'd run a command like:
IMHO that should be python-keyring. Let's not reinvent .netrc again.
I guess the point I've argued myself to here is that I should implement this long form for now, and if a need arises add more conveniences (for example, reading from an environment variable or adding a command to set the defaults). Does anyone disagree too strongly with that?
Yeah. One more thing to think about though. Should lava-tool have per-command auth support (as in your examples above) or some side-band subcommands for auth that would be implicitly picked up by other commands (lava-tool auth ... && lava-tool submit-job ... VS lava-tool submit-job --auth-option ...)
Thanks ZK