Bug 339296

I thought I fixed this in commit cd9b70f1422.

However, ISTR there was some weirdness with the way the plugin was remembering secrets. A checkbox for whether secrets were kept system-wide or per-user, and if you checked the wrong one then it just failed to remember the secrets at all. I only vaguely remember this, and only  looking at it hard enough to establish that it was probably Not My Fault™.

Since the 'autoconnect' option is stored as a "secret" as far as NM is concerned, that might be the cause of this issue.

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 309931, bug 334474

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 309931, bug 334474

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 309931, bug 334474

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 309931, bug 334474

M  +11   -1    kded/secretagent.cpp

http://commits.kde.org/plasma-nm/20e8f2d6924b90492074221a2c3d971eb9c52112