[networkmanagement/nm09] backends/NetworkManager: Fix delayed DBus reply logic (I guess), but GetSecrets still does not

[Lamarque Vieira Souza]

Git commit e428bf150989269ba0a7f9ab050cc76d6e1f6f2c by Lamarque V. Souza.
Committed on 23/05/2011 at 05:50.
Pushed by lvsouza into branch 'nm09'.
Fix delayed DBus reply logic (I guess), but GetSecrets still does not
get the secrets.

The problem is the agent doesn't get properly exported to DBUS at all :/ No
idea why yet...

Maybe it is the bus (session or system), org.kde.networkmangement is in
session bus, NM is in system bus. The migration documentation [1] does not
mention if the user secrets agent must be in the same bus as NM, by what I
read that is not necessary. Well, GetSecrets is called by someone, I guess NM
and although the secrets agent is in session bus it returns the reply through
system bus. I am going to investigate this when I have more time. Looking at
how nm-applet does is a good way to know how the secrets agent should behave.

[1] http://projects.gnome.org/NetworkManager/developers/migrating-
to-09/index.html

[Ilia Kats]

Hey,

if you are referring to line 64 in nmdbussecretagent.cpp, the one with
m_agentManager->Register("org.kde.networkmanagement");
then org.kde.networkmanagement is not the DBus name, but the identifier of the agent (since the naming follows the general DBus rules, I thought it would be a good idea to name it like everything else in KDE NM). The agent is on system bus, as it has to talk to org.freedesktop.NetworkManager on system bus.
And as said in the commit message, nm-applet just stores everything in NM's systemwide storage, even if the "make available for all users" checkbox is unchecked (using 0.8.999, tested with WPA2-PSK).

Besides, GetSecrets is called on connection edits, also SaveSecrets, so this works in principle.

Ilia


-------- Original-Nachricht --------
Betreff: Re: [networkmanagement/nm09] backends/NetworkManager: Fix delayed
DBus reply logic (I guess), but GetSecrets still does not
Datum: 23.05.2011 11:49:29 -0300
Von: Lamarque Vieira Souza <lamarque at gmail.com>
An: Luk?? Tinkl <ltinkl at redhat.com>,kde-networkmanager at kde.org, kde-commits at kde.org

Git commit e428bf150989269ba0a7f9ab050cc76d6e1f6f2c by Lamarque V. Souza.
Committed on 23/05/2011 at 05:50.
Pushed by lvsouza into branch 'nm09'.
Fix delayed DBus reply logic (I guess), but GetSecrets still does not
get the secrets.

The problem is the agent doesn't get properly exported to DBUS at all :/ No
idea why yet...

Maybe it is the bus (session or system), org.kde.networkmangement is in session bus, NM is in system bus. The migration documentation [1] does not mention if the user secrets agent must be in the same bus as NM, by what I read that is not necessary. Well, GetSecrets is called by someone, I guess NM and although the secrets agent is in session bus it returns the reply through system bus. I am going to investigate this when I have more time. Looking at how nm-applet does is a good way to know how the secrets agent should behave.
[1] http://projects.gnome.org/NetworkManager/developers/migrating-to-09/index.html
--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
http://planetkde.org/pt-br
_______________________________________________
kde-networkmanager mailing list
kde-networkmanager at kde.org
https://mail.kde.org/mailman/listinfo/kde-networkmanager

[Michael Biebl]

Post by Ilia Kats
nm-applet just stores everything in NM's systemwide storage, even if the "make

available for all users" checkbox is unchecked (using 0.8.999, tested with
WPA2-PSK).

Secrets can either be stored in the session or system wide.
See
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/ref-migrating.html#id565872

What is always stored system wide is the connection configuration.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-networkmanager/attachments/20110524/8c8545dd/attachment.sig