On Thu, 2015-08-06 at 10:55 +0200, Nikos Mavrogiannopoulos wrote: > On Wed, Aug 5, 2015 at 5:23 PM, David Woodhouse <dwmw2 at infradead.org> wrote: > > > https://github.com/nmav/openconnect-mine/commits/my-changes > > > I carry these patches independently in epel7, openwrt and fedora. > > > Would be nice if they become part of openconnect. > > Those all look fine apart from the top one. I don't like passing extra > > stuff in via stdin like that. If you're using this for form answers, > > hoping that they'll be in the right order, then I'd be *much* happier > > with providing those answers in a form like the one NetworkManager uses > > to store them ? with form and element name, looking something like: > > form.main.username=dwmw2 > > I don't see how could that work. Note that this is about the command > line client. How would a caller find out the form names, and how would > then provide these formatted strings to the client? > > The use case I wanted to handle in openwrt is having two passwords > with the second password being fixed (the rationale was at > http://lists.infradead.org/pipermail/openconnect-devel/2015-June/003037.html > ) I'd rather have something that can solve the *general* use case. And be a little bit more robust in the case where the second input you get asked for *isn't* the one you expected. You could have a mode where the command line client prints the form/item names when it's requesting input. Or even a --dump-form-input mode where it just spits them all out after a successful authentication, in the syntax that it'll accept back again. It's not hard to provide them back to the client ? a series of --form-response= options, which can also come from a config file (which we parse the same as command-line options these days). It also wouldn't be *that* hard to make a fully capable authentication UI that works with luci. I know luci can't do long-running processes but it doesn't need to. You can spawn a separate client which uses libopenconnect but just opens a local UNIX socket for its "user interaction". Then a luci page could get the currently-outstanding form from that UNIX socket and render it. And when the web client POSTs some answers, it can spit those into the waiting UNIX socket. All the answers can (optionally) be remembered and go into the network configuration. And in fact you can also have a mode where the answers *aren't* recorded, and the user needs to manually authenticate to the VPN each time. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150806/6a15848e/attachment.bin>
