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

[David Woodhouse]

On Mon, 2017-08-14 at 11:53 -0700, Daniel Lenski wrote:
> On Mon, Aug 14, 2017 at 8:37 AM, David Woodhouse <dwmw2 at infradead.org
> > wrote:
> > 
> > 
> > On Sat, 2017-05-20 at 15:43 -0700, Daniel Lenski wrote:
> > > 
> > > 
> > > diff --git a/openconnect.h b/openconnect.h
> > > index e97dacb..06bf48e 100644
> > > --- a/openconnect.h
> > > +++ b/openconnect.h
> > > @@ -208,6 +208,8 @@ struct oc_vpn_proto {
> > > 
> > >  #define OC_FORM_OPT_IGNORE             0x0001
> > >  #define OC_FORM_OPT_NUMERIC            0x0002
> > > +#define OC_FORM_OPT_FILL_USERNAME      0x0004
> > > +#define OC_FORM_OPT_FILL_PASSWORD      0x0008
> >
> > Hm... that's a public API, and you're using it for something which is
> > purely internal. That special-casing for 'username' and 'password'
> > fields is something that only openconnect(8) / main.c does.
>
> I see what you mean, but I was thinking that the NM GUI or other GUIs
> could *also* use these to receive hints from the server about the
> correct function of the form fields, rather than (re-)implementing
> their own special-casing.

The thing is, the GUIs don't actually need any special-casing at all.
They can remember the user's answers for *all* form fields.

It's only the command-line openconnect(8) which has special cases for
providing the username and password via command-line options.

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? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170814/b639012d/attachment.bin>