On Thu, 2010-08-26 at 11:08 +0100, David Woodhouse wrote: > 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. Ah, I'm starting to see how this works. It's different from the other VPN clients, hence my confusion. > > > 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. The attached screenshot is what I see at this point, if 'Automatically start...' is not selected. To get the password prompt, I need to click that button in the upper right corner, next to the VPN host selector. > > 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. Right--in that case, I see the password dialog immediately. > > 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. OK Now I see how the dialog works. Thanks for the clarification. > > 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. That would be cool. > > > 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. > My confusion stemmed from not seeing the purpose of the autoconnect option, as we only have one server choice. Now I see what's going on. Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs
Attachment:
Screenshot-Connect to VPN 'Clemson AnyConnect'.png
Description: PNG image
