polkit_authority_check_authorization oddity

[David Zeuthen]

On Wed, 2009-07-15 at 22:50 +0100, Richard Hughes wrote:
> In PackageKit, I do the PolicyKit authentication by setting up a
> PolkitDetails object with some custom data, and then call
> polkit_authority_check_authorization. When this gets actioned, I get
> the GAsyncReadyCallback, and in the case of failure,
> polkit_authorization_result_get_is_authorized returns false.
> 
> If I then do:
> 
> 		details = polkit_authorization_result_get_details (result);
> 		keys = polkit_details_get_keys (details);
> 
> keys is a zero length array. I was at least expecting the action_id of
> what I was trying to authenticate, and hopefully the custom details
> that I had populated before I asked for authentication.

No, that's not how it works, and I'm not sure why you think it should
work that way. Well, I can see where you are coming from and I would
probably have made that connection as well. But that's not how it works.
Allow me to elaborate.

PolkitDetails is just a generic helper class used for all sorts of
different unstructured data (e.g. a property bag). Now, PolkitDetails
should really be a GHashTable (and it used to be) but that type isn't
very friendly to bindings or so all the GI hackers tells me. 

(FWIW, I intent to add GObject Introspection support to
libpolkit-gobject-1 any day now. Then you can easily write system
services in Javascript with polkit support - if that's your kind of
deal ;-) )

Anyway, the intention for returning some details along with the
PolkitAuthorizationResult object is simply to have some wiggle-room for
future features. It is currently unused so right now it will always be
empty...

> I'm trying to get some details about the failure so that I can display
> something more helpful than "failed to obtain auth".

You can just include these things (e.g. the action id and possibly a ref
to the PolkitDetails object) in an object/struct passed as user_data
when issuing the authorization check. Then you can access this from the
GAsyncReadyCallback.

FWIW, I'm not sure it's helpful to include the action_id in user-visible
error messages, though. I mean, such a reverse-DNS-style string is
pretty close to techno-babble. 

It of course make a lot of sense to return a message to the user about
_what_ failed and _why_. But polkit should already tell you this - e.g.
there are basically only three possible answers from polkit when you use
the ALLOW_USER_INTERACTION flag

 o No, the user is not authorized

 o Yes, the user is authorized

 o The authorization check was cancelled
   (either by your own mechanism cancelling the check or by the user
    dismissing the authentication dialog)

Thanks,
David