[prev in list] [next in list] [prev in thread] [next in thread]
List: openconnect-devel
Subject: Re: [PATCH 2/8] add OC_FORM_OPT_FILL_{USERNAME, PASSWORD} flags to hint at purpose of a form field w
From: Daniel Lenski <dlenski () gmail ! com>
Date: 2017-12-17 22:51:31
Message-ID: CAOw_LSEWN2sJWYycKC+Nnvk6fCXRpDzZ=9ZQ=Y-01P4M-L3mFA () mail ! gmail ! com
[Download RAW message or body]
On Mon, Aug 14, 2017 at 12:48 PM, David Woodhouse <dwmw2@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
_______________________________________________
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic