Dne 6.8.2012 17:29, Simo Sorce napsal(a):
On Mon, 2012-08-06 at 16:27 +0200, Jan Cholasta wrote:
Dne 6.8.2012 16:10, Alexander Bokovoy napsal(a):
On Mon, 06 Aug 2012, Jan Cholasta wrote:
Dne 6.8.2012 15:20, Simo Sorce napsal(a):
On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:
Hi,
while thinking about <https://fedorahosted.org/freeipa/ticket/2933>, I
had an idea how to make loading data from files available for all
parameters:
I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them
(similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).
So, instead of adding a new parameter as a file-accepting
alternative to
any existing parameter (i.e. what is suggested in the ticket), the user
would be able to specify the file in a URI-like string:
(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa AAAA ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub
vs.
(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa AAAA ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub
and the CLI would take care of reading the file and using its contents
as the parameter value.
This could be extended with additional URI(-like) schemes:
- data:<data> - use <data> as the value (useful for escaping values
that look like URIs, but you don't want them to be treated as such)
- base64:<data> - use the value of base64 decoded <data> (useful for
--delattr on ugly raw binary values)
- fd:<num> - read value from file descriptor <num>
- env:<var> - read value from environment variable <var>
- ask: - always prompt interactively for the value
- default: - use default value, never prompt interactively
Thoughts?
How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?
Simo.
You can escape them like this: --someparam data:actual://uri/string
As for backward compatibility, this change has the potential to break
things (user scripts which use the CLI, etc.), but AFAIK there is no
parameter in IPA which expects URI string values specifically, so the
impact would be miminal IMHO.
I don't think you need to invent anything here. RFC2397 is available for
long time and provides already effective way to represent any data in
URI.
http://tools.ietf.org/html/rfc2397
I have considered this, but given that these URL-like strings would be
mainly used directly by users on the command-line, I think that
"base64:<stuff>" is more user friendly than "data:;base64,<stuff>".
If you want to propose URIs then use standard URIs please.
Simo.
I don't - URIs are just one of the options we can use.
I think sticking with URIs might be limiting (no relative paths in file
URIs, not everything can be represented by standard URI schemes, etc.),
that's why I called the strings URI-*like* in the original email.
Honza
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
