Problems with authentication - Latest state and summary
pavel.strashkin at gmail.com
Fri May 27 14:23:38 PDT 2011
Could you provide verbose files for both server and client? I see that
server supports ANONYMOUS and sends information to the client about
it, but client doesn't try to use it, only first two (EXTERNAL,
2011/5/25 Bogdan Lotko <boguslaw.lotko at chello.at>:
> The problem is not solved yet, so please help !!!
> In this mail I'll try to order all informations from (somehow) messy
> previous mails.
> My goal is to start a legacy application as a D-Bus service on SuSE 10.3.
> The application is compiled on SuSE 10.3, it uses libdbus-glib-1.so2 and
> The client application that uses the service is the QT application started
> on the remote host running SuSE 11.2.
> The dbus-daemon V. 1.4.1 has been compiled and runs in verbose mode on SuSE
> The dbus-daemon listens on tcp connection
> "tcp:host=192.168.0.10,port=12345". This is the address of the SuSE 10.3
> The .config file (please see attachment) has <allow_anonymous/> statement.
> The remote application authenticates via ANONYMOUS mechanism without any
> The service application attempts to authenticate via EXTERNAL and
> DBUS_COOKIE_SHA1 mechanisms but it fails.
> In case of EXTERNALS D-bus claims lack of credentials, for DBUS_COOKIE_SHA1
> the application responses with "ERROR Don't have the requested cookie Id"???
> ) - please see the attached verbose.txt file.
> The source code of the service application:
> g_type_init ();
> dbus_g_object_type_install_info( MstkBody_TYPE_OBJECT,
> // this works with session D-Bus
> //bus = dbus_g_bus_get( DBUS_BUS_STARTER, &error );
> bus = dbus_g_connection_open( "tcp:host=192.168.0.10,port=12345", &error );
> if (!bus)
> cout << "Couldn't connect to d-bus. " << error->message << ". EXITING" <<
> // This is an essential problem so...
> bus_proxy = dbus_g_proxy_new_for_name( bus,
> "org.freedesktop.DBus" );
> // fails here
> if( !dbus_g_proxy_call( bus_proxy,
> G_TYPE_UINT, DBUS_NAME_FLAG_DO_NOT_QUEUE,
> G_TYPE_INVALID) )
> // exit if this does not work
> cout << "Error calling RequestName: " << error->message << endl;
> The application output looks like:
> Error calling RequestName: Did not receive a reply. Possible causes include:
> the remote application did not send a reply, the message bus security policy
> blocked the reply, the reply timeout expired, or the network connection was
> Please let me know what can I do for the successful authentication?
> - where the credentials come from?
> - why the application does not response correctly to DBUS_COOKIE_SHA1
> - why the SuSE 10.3 application does not use the ANONYMOUS mechanism? Is
> there anything to do?
> With session daemon the authentication of the service application works
> without problems - why?
> with best regards
> Bogdan Lotko
> dbus mailing list
> dbus at lists.freedesktop.org
More information about the dbus