Bug 286856

Summary:	plasmoid-networkmnanagement doesn't ask for vpnc username if the password is to be typed in.
Product:	[Unmaintained] Network Management	Reporter:	Tamás Németh <nt1277>
Component:	general	Assignee:	Will Stephenson <wstephenson>
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	lamarque
Priority:	NOR
Version:	0.9
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Tamás Németh 2011-11-17 15:43:26 UTC

Version:           0.9 (using KDE 4.6.5) 
OS:                Linux

I created a vpnc connection with user authentication, and instructed plasmoid-networkmanagement not to store the user password, but as for it upon connecting. I assume network managements should also ask for the username too, but it doesn't, moreover, it doesn't even display the saved username, so the user doesn't know which username's password is needed.

Reproducible: Didn't try

Steps to Reproduce:
Create a vpnc connection which asks for user password. Try to connect to it.

Actual Results:  
plasmoid-networkmanagement requests the user passoword, but not the username. Moreover, it also lets me to change the group password in spite the fact that I configured it to be permanently saved.

Expected Results:  
Group password (or any other password) shouldn't be asked for when saved permanently, however, username should be able to be changed when user password is asked for.

Comment 1 Lamarque V. Souza 2011-11-20 01:41:14 UTC

Git commit d9f94d62c34ab409c82f62b06a62f1d754f3382e by Lamarque V. Souza.
Committed on 20/11/2011 at 02:39.
Pushed by lvsouza into branch 'master'.

Show user and group names in vpnc authentication dialog. This dialog is
used when NM asks for secrets.

CCBUG: 286856

M  +13   -2    vpnplugins/vpnc/vpncauth.cpp
M  +44   -6    vpnplugins/vpnc/vpncauth.ui

http://commits.kde.org/networkmanagement/d9f94d62c34ab409c82f62b06a62f1d754f3382e

Comment 2 Lamarque V. Souza 2011-11-20 01:42:02 UTC

Git commit f07630fbad6adc10ad26155fdfcbb161989fb295 by Lamarque V. Souza.
Committed on 20/11/2011 at 02:39.
Pushed by lvsouza into branch 'nm09'.

Show user and group names in vpnc authentication dialog. This dialog is
used when NM asks for secrets.

CCBUG: 286856
(cherry picked from commit d9f94d62c34ab409c82f62b06a62f1d754f3382e)

M  +13   -2    vpnplugins/vpnc/vpncauth.cpp
M  +44   -6    vpnplugins/vpnc/vpncauth.ui

http://commits.kde.org/networkmanagement/f07630fbad6adc10ad26155fdfcbb161989fb295

Comment 3 Lamarque V. Souza 2011-11-20 01:45:50 UTC

The stored secrets are still changeable in the dialog because there is the possibility the user saved the wrong secret and now he/she needs to type the correct one.

Implementing saving the user and group names are going to be more complex than I have thought, so I will do it in another time.

Comment 4 Lamarque V. Souza 2011-11-20 02:47:21 UTC

I have just implemented saving user and group names from authentication dialog. Now I realise it is not going to work in the first run because NM is going to try using the old user and / or group names before updating them. It will work in a second run though.

By what I see in NM source code it was not designed to change non-secret data from secret agents.

I think it is better not commit this patch until NM has proper support for updating non-secret data from secret agents.

NM automatically updates secrets that comes from an authentication dialog, which generates an "update secrets" inside NM. The point is that my implementation calls NM to update the connection right after returning the secrets to NM. I do not know which update is going to take effect first: the one when NM reads the secrets or the second one I do after returning the secrets. I guess it is the former, but if NM is multi-threaded it can be any of them and that can lead to a race condition.

Comment 5 Lamarque V. Souza 2011-11-20 19:03:51 UTC

Can I close this bug? As I wrote in my last comment NM should have proper support to updating non-secret data from secret agents to support your request and showing the "Store" marked secrets are usefull when you stored the wrong the secret.

Comment 6 Tamás Németh 2011-11-22 17:25:55 UTC

(In reply to comment #5)
> Can I close this bug? As I wrote in my last comment NM should have proper
> support to updating non-secret data from secret agents to support your request
> and showing the "Store" marked secrets are usefull when you stored the wrong
> the secret.

So, you mean, this problem could be handled in KDE only if the underlying NetworkManager would have a special support for it?

Comment 7 Lamarque V. Souza 2011-11-22 17:54:49 UTC

(In reply to comment #6)
> (In reply to comment #5)
> > Can I close this bug? As I wrote in my last comment NM should have proper
> > support to updating non-secret data from secret agents to support your request
> > and showing the "Store" marked secrets are usefull when you stored the wrong
> > the secret.
> 
> So, you mean, this problem could be handled in KDE only if the underlying
> NetworkManager would have a special support for it?

For the "saving settings while activating a connection" the answer is yes. What happens is the following: Plasma NM contacts NM to activate a connection, NM notices it needs secrets to activate it, NM contacts the secret agent to provide the secrets, Plasma NM's secret agent answers the request.

The secret request's answer includes only secrets, not settings. What I did is send an Update call to NM to save the connection with the new settings, but probably NM has already tried to connect with the old secrets before my request arrives in NM.

The best solution is if Plasma NM could send settings along with secrets in the secret request's answer, which NM does not support at the moment as far as I know.