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://docs.google.com/document/d/1inf_HhRPdyERMBlET01baTnoeqeYXn0pUvzlBuE0m0k/edit#heading=h.ug99hyx6imji
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?
** Changed in: online-accounts-api (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1602159
Title:
Manager class only provides access to one (random?) service ID for an
account
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/online-accounts-api/+bug/1602159/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
