* Global rename of NMConnectionSettings -> NMExportedConnection to cut down
on confusing names
* Add 'path' and 'scope' properties to NMConnection since both NM and the
applet were having to hack this in anyway. Remove the 'path' stuff from
NMExportedConnection
* Internally rename NMConnectionType -> NMConnectionScope
* Provide default implementations of the 'get_id' and 'get_settings' methods
of NMExportedConnection
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3334 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
Split the GetSecrets() call off to a separate D-Bus interface so that it
can be more easily locked down with D-Bus policy. Only 'root' (ie, NM)
should be able to call GetSecrets().
* include/NetworkManager.h
- Define the connection secrets D-Bus interface
* src/vpn-manager/nm-vpn-connection.c
- (clear_need_auth): get the right proxy object for the connection
secrets interface
- (get_connection_secrets): use the connection secrets proxy; send
empty hints in get secrets request
* src/nm-activation-request.c
- (nm_act_request_request_connection_secrets): use the connection
secrets proxy; send empty hints in get secrets request
* src/nm-manager.c
src/nm-manager.h
- (connection_get_settings_cb): set the connection secrets proxy on
the connection object too
- (internal_new_connection_cb): create the connection secrets proxy
* introspection/nm-settings-connection.xml
- Define Connection.Secrets interface and move GetSecrets there
- Add a 'hints' argument to GetSecrets
* libnm-glib/nm-settings.c
libnm-glib/nm-settings.h
- (impl_connection_settings_get_secrets): add 'hints' argument
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2989 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
Properly re-query secrets from the settings daemon when stuff fails.
* src/nm-device-802-11-wireless.c
- (ap_auth_enforced): handle static WEP correctly here by differentiating
between Shared Key and Open System auth modes
- (link_timeout_cb, supplicant_connection_timeout_cb,
real_act_stage4_ip_config_timeout): clear existing secrets and
request new ones when something fails due to a suspected wrong key
- (real_act_stage2_config): fix for new request_new argument to
nm_manager_get_connection_secrets()
* src/nm-manager.c
src/nm-manager.h
- (nm_manager_get_connection_secrets): return error status; pass
new request_new argument on to the settings daemon
* introspection/nm-settings-connection.xml
- New 'request_new' argument to the GetSecrets call that hints to the
settings daemon to ask the user for completely new secrets
* libnm-glib/nm-settings.c
libnm-glib/nm-settings.h
- (impl_connection_settings_get_secrets): handle new 'request_new'
argument
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2872 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
* introspection/nm-settings-connection.xml
libnm-glib/nm-settings.c
libnm-glib/nm-settings.h
- Make GetSecrets asynchronous on the server side
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2829 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
Stupid mistake on my part; object path and interface for settings service
and connection objects can be the same, only the service name must be
different for the system and user settings services.
* include/NetworkManager.h
src/nm-manager.c
introspection/nm-settings-connection.xml
introspection/nm-settings.xml
libnm-glib/nm-settings.c
- (nm_connection_settings_init, query_user_connections,
new_connection_cb): Unify NetworkManagerSettings and Connection
interface name and object path
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2772 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
* introspection/nm-settings-connection.xml
introspection/nm-settings.xml
- Service name -> NetworkManagerUserSettings because two services
can't share part of the same path. I'm not really sure how we'll use
the same code with the system-settings daemon...
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2744 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
