[Freeipa-devel] Data source-agnostic parameters

[Jan Cholasta]

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>".

Honza

-- 
Jan Cholasta