[Freeipa-devel] Data source-agnostic parameters

[Jan Cholasta]

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