© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
eee2d0b
(Get the code!)
The new API has been built with the assumption that each client application will have access at most to one service per account.
See the last paragraph in
https:/
Now, this means that the service should never return the same account ID twice, but you found a case where this is not true. This is probably a bug, but please read on.
The new API is more limited than the old one, and has been designed to support click apps and scopes. For these clients, we expect to be able to identify them by their app-id, either by inferring it from their apparmor label or (for unconfined processes) by receiving it as an explicit parameter.
Your gdbus invocation doesn't fall in either of these scenarios, because what we get is a request from an unconfined process which does not specify an "applicationId" parameter.
I believe that if you add such an "applicationId" parameter pointing to a valid application ID, you will not get any accounts listed twice. If that's not the case, please let me know.
Now, what is certainly true is that in this specific case the API does not behave in a deterministic way. I would suggest that we "morph" the bug about having an explicit D-Bus error when an unconfined client makes a request without specifying an "applicationId" parameter. WDYT?