On Thu, Aug 6, 2015 at 11:57 AM, David Woodhouse <dwmw2 at infradead.org> wrote: >> 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. Correct, but the current use case (a second _fixed_ password) doesn't warrant such a wide change. The current change is pretty safe also, in the sense that is fully backwards compatible and simple, in the sense that requires no interaction with the server to set it up. Moreover it is safe as it will only read as many lines as provided by stdin (in openwrt that is a file). > 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. That's a paradigm change for the existing code in openwrt and the use-cases we need to handle currently don't justify that. In fact I don't see any benefits from such a change. The openwrt interface allows configuring openconnect (even when the router is offline), for a non-interactive authentication. Even if we had the resources to implement that big change, we wouldn't be able to handle use cases other than that dumb use-case with a second fixed password. So it feels like you are proposing a very generic framework that requires too many changes in openconnect and openwrt interface with no visible advantages for the use-cases handled in openwrt. regards, Nikos
