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
