Because most of the time they will. They need special handling all
around anyway because only the VPN plugin itself knows whether the
connection needs secrets.
The old function took a string value, which wasn't really correct as
the property type is a GHashTable of string:string. For whatever
reason this is how nm-applet passed VPN secrets back to NM in the return
from the GetSecrets() D-Bus call. This was probably easier or
something but it was a special case that's magic and quite unclear.
Since we use nm_connection_update_secrets() more these days, and we
depend on the GValue types we pass into it matching the property
types of the setting property the secret is for, we need to fix that
up for VPN connections. But keep the old code for backwards
compatibility.
In the future secret agents should pass back VPN secrets in the same
form as the VPN setting specifies them for the "secrets" property:
a GHashTable of string:string. But the old mechanism of just dumping
the key/value pairs into the returned VPN hash as string:string will
still work.
Not all connections will require every secret, and sometimes we
can't automatically figure out whether we need the secret. For
vpnc sometimes the group password isn't used, and sometimes PPP
providers require a username but don't want a password, etc.
Becuase there's only one 'flags' property for WEP keys (because it's pretty
dumb to have different flags for all 4 WEP keys) we need to do some tap dancing
with the secret name, so that requests for "wep-keyX" look up the "wep-key-flags"
property.
This allows the necessary flexibility when handling secrets; otherwise
it wouldn't be known when NM should save secrets returned from agents
to backing storage, or when the agents should store the secrets. We
can't simply use lack of a secret in persistent storage as the indicator
of this, as (for example) when creating a new connection without
secrets the storage method would be abmiguous.
At the same time, fold in "always ask" functionality for OTP tokens
so user agents don't have to store that attribute themselves out-of-band.
There was never a property for it anyway, so it never got serialized
across D-Bus, because it was folded into the "password" property in
wpa_supplicant between 0.5 and 0.6.
The first-level hash table key should be the setting name itself,
not the GType name of the setting's GObject. There's probably a
better way to do this to reduce that confusion.
Simplifies code internally, and makes it easier for clients as well in
some cases where they want to control what ends up in the resulting
hash and what does not.
Add the necessary annotations (the mininum required, that is those
on return values. NULL parameters or container types may require
more), and the Autotools stuff to get a NetworkManager GIR for
libnm-util and a NMClient for libnm-glib.
If a pointer to a valid GError was not passed the function could
crash. Make it simpler and fix the possible crash by just converting
to hash table iters instead.
Presently, when automatic connecting fails, the connection is marked
as invalid and is not retried again. This commit adds a configuration
parameter to specify how many times the connection should be re-tried.
Connections are normally created from hashes using g_object_set()
which calls that object's set_property handler. But GObject does
not allow errors to be returned from property handlers, so if the
type doesn't match what it should be, the property does not get
set, and error is printed to stdout, and life goes on.
But that's not what we want for the permissions property since the
client might expect that property to be set, but the connection now
is available to everyone. So validate the permissions property
type (its really the only one we need to be so paranoid about)
and return an error when the incoming property type is wrong.
Groups may come later, but they are also quite a bit more complicated
because getting the groups a user is in may require network access
if that user is backed by LDAP. And it gets worse because you have
no idea that the glibc calls like getgrouplist(3) are backed by
the network and may take an arbitrary amount of time to complete.
Punt that.
