GNOME Bugzilla – Bug 704263
[review] dcbw/need-secrets: request secrets asynchronously (openvpn)
Last modified: 2013-08-02 20:41:58 UTC
This is the OpenVPN counterpart to bug 703277 (vpnc) and bug 703276 (NM). Kick off an async need-secrets request when openvpn asks us for secrets via the management interface. This branch requires *no* patches to openvpn as the management interface is already capable enough of indicating when secrets are needed. Since that's the case, the NM-openvpn plugin now always uses the new RequestSecrets signal since the management interface will always ask for what's needed. However, any secrets given in the original connection request are still passed to the plugin to minimize password dialogs. (this does mean that if you have both a VPN password and eg an HTTP proxy password, you would now get one password dialog for each required secret if the secrets were not yet stored in your keyring. But if they are already stored in the keyring already, then they should be passed to the plugin at Connect() time early in the process and no additional dialogs will be shown)
yeah, i think this is right > if (out_failure) >- *out_failure = NM_VPN_PLUGIN_FAILURE_CONNECT_FAILED; >+ *out_failure = NM_VPN_PLUGIN_FAILURE_CONNECT_FAILED; accidental stray spaces? it was right before So, this will break the gnome-shell mode, won't it?
Spacing fixed. Actually I don't think it'll break the shell mode since all the new logic happens before the external-ui-mode decision, and all it does is change the prompt and which passwords are displayed.
(In reply to comment #2) > Spacing fixed. > > Actually I don't think it'll break the shell mode since all the new logic > happens before the external-ui-mode decision, and all it does is change the > prompt and which passwords are displayed. Well, the shell would need to run the dialogs with the new "-t" argument to pass hints along, so yeah, but it shouldn't require any more work than that.
Re-pushed with fixes for ConnectAsyncAllowed() which fixes the hints problem with old agents.
(In reply to comment #2) > Actually I don't think it'll break the shell mode since all the new logic > happens before the external-ui-mode decision, and all it does is change the > prompt and which passwords are displayed. Hm... ok, I'm getting the different VPN parts confused I think. So in the case of, like, next-token-code, NM would launch the VPN service, which would request username and password, then NM would pass that request to gnome-shell, which would invoke "nm-openvpn-auth-dialog --external-ui-mode -t $HINTS", then put up a password dialog and return the data to NM, which would return the data to nm-openvpn-service, which would send it to the openvpn server, which then asks for *another* password, so nm-openvpn-service would do another secrets request, NM would make another call to gnome-shell's agent, gnome-shell would again call nm-openvpn-auth-dialog, put up another password dialog, etc, etc. OK. That works. New code looks good
(In reply to comment #5) > (In reply to comment #2) > > Actually I don't think it'll break the shell mode since all the new logic > > happens before the external-ui-mode decision, and all it does is change the > > prompt and which passwords are displayed. > > Hm... ok, I'm getting the different VPN parts confused I think. So in the case > of, like, next-token-code, NM would launch the VPN service, which would request > username and password, then NM would pass that request to gnome-shell, which > would invoke "nm-openvpn-auth-dialog --external-ui-mode -t $HINTS", then put up > a password dialog and return the data to NM, which would return the data to > nm-openvpn-service, which would send it to the openvpn server, which then asks > for *another* password, so nm-openvpn-service would do another secrets request, > NM would make another call to gnome-shell's agent, gnome-shell would again call > nm-openvpn-auth-dialog, put up another password dialog, etc, etc. OK. That > works. Yes, pretty much. The hard part is that the *second* secrets request is for a specific secret, specified by the VPN server or service itself, and without hints the auth dialog can't ask for and return what the VPN actually wants. Thus the requirement that agents handle hints.
merged to master, thanks!