On 05/09/2016 04:02 AM, David Woodhouse wrote: > Thanks for looking at this. I'm still slightly concerned about exposing > this to users in its current form ? I'd like to pass the HTML directly > for rendering, instead of using our half-baked parser which can only > handle the trivial common cases in the Juniper example forms. I agree this approach is a better way; but unfortunately it's also more than I'm willing to bite off. Sorry. > Could we drop the boolean NM_OPENCONNECT_KEY_JUNIPER_MODE and just have > a string key that contains exactly the string that's passed to > openconnect_set_protocol(), please? The problem is that while the authentication piece uses the OpenConnect library, NetworkManager itself kicks off openconnect via the command line (see the change to nm_openconnect_start_openconnect_binary). So unless you are prepared to change the OpenConnect command line to take a parameter like --vpn-type, NetworkManager will need to know some details about the type of VPN. > And if it's absent/empty then we do > nothing and hence default to AnyConnect. That makes it nice and generic > and easier to support other VPN protocols in future. We do have at > *least* Junos Pulse in the works ? I have it decoded, and just need to > find the time and motivation to hook up all the EAP nonsense. Or > preferably a willing volunteer who actually *uses* it :) I can test Junos Pulse as well. > Can we make this appear to NetworkManager as two *separate* plugins, > that just happen to use (mostly) the same binaries? The properties > plugin does have the name hard-coded so it can't be *entirely* the same > binaries... but see GNOME bug #765732 where the GTK parts are all taken > out into a *separately* loaded library anyway, so that can still be > shared while the plugin itself is built for both Juniper and > AnyConnect, returning different values for PROP_NAME/PROP_DESC? Yes, I'm happy to take a crack at this. --Ian
