On Mon, 2017-08-14 at 11:53 -0700, Daniel Lenski wrote: > On Mon, Aug 14, 2017 at 8:37 AM, David Woodhouse <[email protected] > > 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? :)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/openconnect-devel
