[Authentication] Open Issue: Passwords for new Collections

[Stef Walter]

Michael Leupold wrote:
> Thus I'd prefer:
> Method: Boolean ChangeAuthentication(object, window-id);
> - objects is the object to change authentication for (collections and/or 
> items)
> - return value is false, if changing the authentication for that object is 
> not supported (ie. it's an item and the service handles authentication per 
> collection)
> Signal: AuthenticationChanged(object, Boolean);
> - async return for ChangeAuthentication
> - second argument is false if changing the authentication failed

Snipped lots of good advice...

Okay, I've given this a lot of thought. What this essentially means is
that we need a method by which to make asynchronous calls in our API.
That is some calls may not return their results immediately.

APPROACH ONE: METHOD CALLS + SIGNALS (UGLY)

One approach is to try and use method calls + signals, as suggested
above. It looks good on the surface.

The sad thing, is this is extremely problematic to actually implement.
It's full of race conditions and all sorts of problems. This approach
has been bandied about by various dbus developers.

The method calls + signals approach is realistic for a small subset of
asynchronous operations. Our BeginAuthenticate and friends was one of
those. Because it had very few guarantees, we could dance around the
race conditions, visibility problems and other issues.

CreateCollection and ChangeAuthentication require a much stronger async
calls. For example they require the following (remember this is per
invocation):

 * Errors to be returned.
 * Cancellation (of at least prompts).
 * Successful completion notification.
 * Returning results.
 * Timeouts?

I've gone into this subject before on this mailing list ... but a great
explanation of the problems in making an async API with method calls +
signals can be found in this post written by Scott James Remnant:

http://marc.info/?l=freedesktop-dbus&m=121675537300488&w=2


APPROACH TWO: DBUS ASYNC CALLS + CANCELLATION

I've given a lot of thought to a second approach which I believe has
none of the race condition and other problems of approach one.

We would use standard async DBus calls. This already give us per
invocation errors, completion notification, results, and timeouts where
needed. The client would make a call like CreateCollection
asynchronously. The call would not return a reply DBus message until the
create operation completes or fails.

The one thing missing from this scenario is cancellation. In order to do
cancellation, the Service sends a signal whenever it's about to do some
prompting. In this signal is the unique serial number of the DBus call
that caused the prompting. The Service has a CancelPrompting() method
which allows the client to use the unique serial number to do cancellation.

The only draw back is that the clients must specify a long timeout for
their DBus message calls. This is an issues that has been brought up
many times on the DBus mailing list. I'd rather accept this one wart,
than all the massive problems then approach one gives us.



Attached is a patch which includes approach two in our secrets service
API. Thanks for reading this far.

Cheers,

Stef

-------------- next part --------------
A non-text attachment was scrubbed...
Name: secrets-service-api-prompting.patch
Type: text/x-diff
Size: 13148 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/authentication/attachments/20091023/0c4a6aca/attachment.patch