[Freeipa-devel] Data source-agnostic parameters

[Alexander Bokovoy]

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


-- 
/ Alexander Bokovoy