I can't seem to find a way to store the username and password for my OpenConnect VPN connection. I define a VPN connection specifying OpenConnect where I specify the Gateway to use. There is no way for me to specify the username/password to use there. When I connect to this new VPN connection, I am first prompted that the VPN certificates are not trusted and when I choose to ignore that and continue connecting anyway I'm presented with a username/password dialog. I cannot choose to remember the certificate exception in any way and furthermore I cannot choose to remember the username/password either. I can choose to "Automatically start connecting next time" but that seems to have no effect at all. It does not remember the username/password and doesn't even seem to try to connect automatically. Reproducible: Always Steps to Reproduce: 1. Define a new OpenConnect VPN in the connection editor 2. Connect to it (and be unable to remember password but you can try to check "Automatically start connecting next time") 3. Disconnect from it. 4. Connect to it again and notice that you get prompted for the username/password.
I can confirm the same problem. This is very annoying to have to type username/password each times.
We have to rework OpenConnect VPN plugin, because we still have old version from the old networkmanagement applet, but unfortunately we had no time to do that so far as there are so many things to do, like porting to Plasma Next.
Git commit 4bb0e742dd9f8cede51af590c4a228656e8a73d9 by Jan Grulich. Committed on 08/01/2015 at 12:44. Pushed by grulich into branch 'master'. Do not return an empty map with secrets This is causing some issues in secret agent from plasma-nm, because it always tries to store VPN secrets to KWallet even when the map is empty and when it loads this empty map later it overwrites the secrets we get from NetworkManager in GetSecrets method and thus when plasma-nm displays the auth dialog it doesn't have necessary secrets available. Related: bug 339296, bug 309931 M +3 -1 src/settings/vpnsetting.cpp http://commits.kde.org/networkmanager-qt/4bb0e742dd9f8cede51af590c4a228656e8a73d9
Git commit 1da5311c003b598ca5d371a1e814847ffcf8d608 by Jan Grulich. Committed on 08/01/2015 at 12:41. Pushed by grulich into branch 'master'. Workaround: make sure we don't send completely empty map to NM back when asking for VPN secrets When NM asks for secrets, which should be system-owned (stored in NM), it also asks our secret agent from some reason if we have them, but if we send back an empty map, it won't ask again with required flag which would invoke displaying an auth dialog. We have to send back a map containing "secrets" key which should be without any value. It worked before that way because in NetworkManagerQt we always returned this map with secrets even when it was empty. Related: bug 339296, bug 309931 M +11 -1 kded/secretagent.cpp http://commits.kde.org/plasma-nm/1da5311c003b598ca5d371a1e814847ffcf8d608
Git commit 5c908dfb4b075d001cd1f2b43494e19ed18f1ba1 by Jan Grulich. Committed on 08/01/2015 at 12:44. Pushed by grulich into branch 'NM/0.9.8'. Do not return an empty map with secrets This is causing some issues in secret agent from plasma-nm, because it always tries to store VPN secrets to KWallet even when the map is empty and when it loads this empty map later it overwrites the secrets we get from NetworkManager in GetSecrets method and thus when plasma-nm displays the auth dialog it doesn't have necessary secrets available. Related: bug 339296, bug 309931 M +3 -1 settings/vpnsetting.cpp http://commits.kde.org/networkmanager-qt/5c908dfb4b075d001cd1f2b43494e19ed18f1ba1
Git commit 20e8f2d6924b90492074221a2c3d971eb9c52112 by Jan Grulich. Committed on 08/01/2015 at 12:41. Pushed by grulich into branch '0.9.3'. Workaround: make sure we don't send completely empty map to NM back when asking for VPN secrets When NM asks for secrets, which should be system-owned (stored in NM), it also asks our secret agent from some reason if we have them, but if we send back an empty map, it won't ask again with required flag which would invoke displaying an auth dialog. We have to send back a map containing "secrets" key which should be without any value. It worked before that way because in NetworkManagerQt we always returned this map with secrets even when it was empty. Related: bug 339296, bug 309931 M +11 -1 kded/secretagent.cpp http://commits.kde.org/plasma-nm/20e8f2d6924b90492074221a2c3d971eb9c52112
Git commit ae412aa60e400f9f53c59e42def8b78226b21961 by Jan Grulich. Committed on 13/01/2015 at 15:27. Pushed by grulich into branch 'master'. Make NM to store Openconnect secrets into KWallet REVIEW:122012 Related: bug 309931 M +36 -0 kded/secretagent.cpp M +13 -2 vpn/openconnect/openconnectauth.cpp M +7 -0 vpn/openconnect/openconnectwidget.cpp http://commits.kde.org/plasma-nm/ae412aa60e400f9f53c59e42def8b78226b21961
Git commit 35effa11540bbec8b6d13aa520656b270b31728e by Jan Grulich. Committed on 13/01/2015 at 15:27. Pushed by grulich into branch '0.9.3'. Make NM to store Openconnect secrets into KWallet REVIEW:122012 Related: bug 309931 M +36 -0 kded/secretagent.cpp M +12 -2 vpn/openconnect/openconnectauth.cpp M +7 -0 vpn/openconnect/openconnectwidget.cpp http://commits.kde.org/plasma-nm/35effa11540bbec8b6d13aa520656b270b31728e
Git commit cae27f8e6e34f806f83d524b032968b15fde4ea9 by Jan Grulich. Committed on 13/01/2015 at 15:27. Pushed by grulich into branch 'Plasma/5.2'. Make NM to store Openconnect secrets into KWallet REVIEW:122012 Related: bug 309931 M +36 -0 kded/secretagent.cpp M +13 -2 vpn/openconnect/openconnectauth.cpp M +7 -0 vpn/openconnect/openconnectwidget.cpp http://commits.kde.org/plasma-nm/cae27f8e6e34f806f83d524b032968b15fde4ea9
This may or may not be related, but I had this bug as well, and I could at least manually enter the username and password, but I am now no longer even greeted wtih the dialog for doing so. When I try to connect to my vpn, all I get is a Plasma 5 notification saying that it failed to get secrets. I'm using version 5.4.1 on Kubuntu 15.10.