On Sun, 2016-05-15 at 13:23 -0400, Ian Turner wrote:
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.
Understood. I'm more mentioning it to explain my reticence about exposing Juniper mode in NetworkManager. But I think the time has come to do it (NM support) anyway, incomplete though it is. It does work for a lot of people already.
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.
Good point. I've added a --protocol option on the command line: http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/67ba82a We can still special-case "nc" → "--juniper" in nm-openconnect-service for now, to avoid *requiring* the new version. But before adding any new protocols (i.e. Pulse) we'll add a proper way of querying which protocols are supported, and make sure we use --protocol in future.
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.
Yeah, someone just needs to write the support. Perhaps I should list it as a GSoC project for next year...
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.
Great, Thanks! -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature