[PATCH 2/8] add OC_FORM_OPT_FILL_{USERNAME, PASSWORD} flags to hint at purpose of a form field without requiring a specific name

[Daniel Lenski]

On Mon, Aug 14, 2017 at 12:48 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> > Besides... if I look in your auth-globalprotect.c it looks like you're
>> > generating the field names out of thin air anyway. If you had used
>> > "username" and "password" instead of "user" and "passwd" then this
>> > wouldn't have been necessary at all, would it? :)
>> I did that at first, but then I had to special-case-rename the fields
>> to user and passwd when submitted them as an HTML form.
>>
>> I rewrote it with the hints because I thought it'd be more useful to
>> have this general-purpose mechanism for recognizing the purpose of the
>> fields independently from their names.
>
> Yeah, I do see that point. I'm really wary of making promises we can't
> keep though. We have to make lots of assumptions and special cases in
> the command-line code — especially in Juniper auth where I'd *really*
> like the GUIs to just use a WebView instead. But for the GUI side I was
> trying not to make so many.
>
> How about we stick with strncmp() on the first four letters for now,
> and we can work something better out later. I'm leaning towards fixing
> the general case of form fields in main.c by allowing something like
> '--form-opt main:username=dwmw2', and then the --user and --passwd
> special cases just become appropriate invocations of the same 'add
> stored option' function, with the name of the form option being
> protocol-specific. So instead of *:username we'd match main:username
> for Cisco, and whatever:username for Juniper. And whatever:user for
> GPST.

The patch that you recently added to support Juniper form fields with
a type of "username"
(http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/fdaba772b27d66f92a3d035d18d7b4e15292f6b9)
is another example of where openconnect UIs would benefit from having
a hint about the *purpose* of a form field independent from its
*name*. I suppose a Juniper form field could have type=username, but
name=i_like_monkeys.

With the OC_FORM_OPT_FILL_{USERNAME,PASSWORD,TOKEN} flags that I
proposed, this could be handled very easily, even if not as thoroughly
as your proposed approach for general-purpose form field overrides.

Just something to think about…

-Dan