On Sat, 2010-08-21 at 13:17 -0400, Matthew Saltzman wrote: > I notice that the OpenConnect plugin behaves differently from the other > VPN clients. In particular, it doesn't seem to be able to save a > password in the keyring and log in without requiring human intervention > to enter a password in a pop-up dialog.
We don't have gnome-keyring support for storing passwords yet. Patches to add it would be massively appreciated. Remember, the server can give you *arbitrary* web forms. Currently we remember user's responses for 'select' or 'text' input fields, but not 'password' input fields. An acceptable patch would make it cope with arbitrary input fields marked as 'password', too. Not just a single password. And presumably we'd want to be able to store passphrases for SSL keys? In fact, it would *also* be useful to use the keyring for storing the successful login 'cookie', so that you don't have to re-authenticate. Even if it can be automatic, we don't want to re-authenticate because that means you get a *new* IP address, due to Cisco's crappy IP allocation code. (Please file a ticket with Cisco about that, if you are able -- when user X logs in again within a few seconds of her previous disconnection, even if the IP address she previously had is still available in the pool, she doesn't get that same IP address back again. She gets a new IP address, and all her existing connections into the VPN are broken. This is a completely inadequate IP address allocation setup, and they ought to be ashamed of it.) If we get a connect request, and the keyring has a valid cookie which still has sufficient time left before it expires, then we should use that cookie rather than getting a new one. > And there's this odd state where you have to click a button to start > the login process if there isn't an option selected with a check box. Forgive me if I'm being dim, but I'm not entirely sure what you mean here. For reference for the peanut gallery, this is the kind of thing we're looking at: http://david.woodhou.se/nm-openconnect-auth.png When you ask NetworkManager to connect to the VPN, it runs the nm-openconnect-auth-dialog tool and waits for it to spit out the IP address of a server to connect to, and an HTTP cookie to use for authentication. The auth-dialog first has to choose between a number of different servers. This list is automatically updated, from an XML configuration file which is downloaded from the server after each successful login. When you select a 'VPN host' from the combobox, it'll immediately start connecting to that host and will display the forms that the host presents for authentication. Or if you've checked the 'Automatically start connecting next time' option, it'll automatically start connecting to the last host you successfully connected to, and you don't have to click anything. Next there's the form itself. "Forms", actually, since you can get lots of them one after the other. The dialog will just let you fill in web forms repeatedly, until you're rewarded when the successful HTTP cookie that you need to actually make the VPN connection. And then of course it exits and gives NM the IP address and the cookie it was waiting for. My example screenshot above shows a fairly traditional form where the entry fields include 'username' and 'password', but it really doesn't have to look like that. As I said above, we do currently remember the user's input for all the input fields which are marked as 'choice' or 'text' -- so the GROUP and Username entries in the example are automatically filled in for you. As I said, patches would be welcome to use the keyring to store 'password' input fields too. Once keyring support is implemented and you ask NM to connect to the VPN, you would get *directly* to the state I show in my screenshot, where all you have to do is click once on the 'Login' button to actually go ahead and log in with the responses that it remembers. Once we get to that point, it would certainly make sense to see how we could eliminate the need for that click on the 'Login' button -- the dialog could automatically attempt to log in, if it has answers to all the input fields. There are plenty of details to think about to make sure we get this right and it doesn't submit out-of-date remembered answers, but it's certainly feasible. > Is there a reason that's different here, and/or are there plans to > change it? There are certainly plans to implement keyring support, but they're mostly of the "I hope someone does it and sends me patches" variety. I'm open to all kinds of other changes if you can help me understand how it can be better. I'm not really sure I understood what you meant by having to 'click a button to start the login process' -- the only button I have to press is the Enter button, after typing my password. And we can't eliminate that until *after* we implement keyring support. -- David Woodhouse Open Source Technology Centre [email protected] Intel Corporation _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
