Description of problem: if "filter: ..." header is set, do not return links that the user has no permission to access. Version-Release number of selected component (if applicable): si19.1 / 3.1.0-18 How reproducible: always Steps to Reproduce: 1. curl -u regular_user ... -H "filter: true" https://rhevm.example.com/api 2. curl -u regular_user ... -H "filter: true" https://rhevm.example.com/api/users 3. Actual results: 1. ...<link rel="users" .../> 2. permission denied Expected results: 1. this link is omitted from results Additional info:
one clarification: omit results inaccessible to user with that mode of filtering on - don't show "administrative" links to user with "filter: false" or unset and don't show user-only links (if any) to user with "filter: true"
this is not feasible, permission based filtering done on a backend side, api is a pipe to backend only, implementing user aware context in api is incorrect from business logic PoV and will override backend rules, api considerate only representation logic (which is works perfectly from REST PoV)
closing based the fact that we also return all actions regardless of resource state what is justified by the stateless nature of api and Comment 2.
apparently we have another use case where user should not see collections regardless of his permissions, such as /disks, /networks etc., (i.e this is admin only collections) this is a only case where api collection resources should be filtered out in user api.
Posted patch: http://gerrit.ovirt.org/8781 It removes the unsupported resources from the API resource for filtered requests: <link rel="events" href="/api/events"/> <link rel="events/search" href="/api/events;from={event_id}?search={query}"/> <link rel="hosts" href="/api/hosts"/> <link rel="hosts/search" href="/api/hosts?search={query}"/> <link rel="networks" href="/api/networks"/> {query}"/> <link rel="tags" href="/api/tags"/> <link rel="users" href="/api/users"/> <link rel="users/search" href="/api/users?search={query}"/> <link rel="groups" href="/api/groups"/> <link rel="groups/search" href="/api/groups?search={query}"/> <link rel="vmpools" href="/api/vmpools"/> <link rel="vmpools/search" href="/api/vmpools?search={query}"/> <link rel="disks" href="/api/disks"/> <link rel="disks/search" href="/api/disks?search={query}"/>
after thinking on this a bit more, mentioned solution won't scale from the client PoV, for instance we will have to generate two sdks, one for admins and another one for non-admins ..., moving this bz to feature for future discussion.
*** Bug 868921 has been marked as a duplicate of this bug. ***
link : http://gerrit.ovirt.org/#/c/8987/ hash : 687fcf3b31ca5627bc31187097321197a9f2f42c
*** Bug 872147 has been marked as a duplicate of this bug. ***
*** Bug 874705 has been marked as a duplicate of this bug. ***
link : http://gerrit.ovirt.org/#/c/8987/ Hash : I54b79dc86e4f6d6b28c5e720200b093d246f0806
Created attachment 653601 [details] r-v debug output I managed to hit yet another error shortly after the r-v actually connected - not sure if it is the same or something else...
(In reply to comment #16) > Created attachment 653601 [details] > r-v debug output > > I managed to hit yet another error shortly after the r-v actually connected > - not sure if it is the same or something else... Does look like the exception is related to this bug
Should user have access also to /tags url? Because it is still returning "query execution failed due to insufficient permissions."
(In reply to comment #19) > Should user have access also to /tags url? > Because it is still returning "query execution failed due to insufficient > permissions." Simon?
(In reply to comment #20) > (In reply to comment #19) > > Should user have access also to /tags url? > > Because it is still returning "query execution failed due to insufficient > > permissions." > > Simon? I don't recall we have any permission model for tags, Miki?
(In reply to comment #21) > I don't recall we have any permission model for tags, Oved?
(In reply to comment #22) > (In reply to comment #21) > > I don't recall we have any permission model for tags, Oved? Well, I saw two parts of permissions for tags: 1. In webadmin, the administrator can assign a tag for users/groups, and when asking for tags the user will only get tags that are part of his user or groups he is a member of. 2. All the queries to get tags are not user queries, so the user is not allowed to run them at all, that's why it fails for user queries. So the question here is whether or not we want users to see tags. Simon?
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #21) > > > I don't recall we have any permission model for tags, Oved? > > Well, I saw two parts of permissions for tags: > 1. In webadmin, the administrator can assign a tag for users/groups, and > when asking for tags the user will only get tags that are part of his user > or groups he is a member of. > 2. All the queries to get tags are not user queries, so the user is not > allowed to run them at all, that's why it fails for user queries. > > So the question here is whether or not we want users to see tags. > Simon? OK, thanks, now I understand the question. No, users should not be allowed to see tags since they can't use them in the first place. To see a tag a user has to have Admin permissions and not just user permissions. The behavior should be similar to the UI in this case. Generally, the same concept as the UI should be applied. If a user has access to the webadmin then he is also allowed to see the same object in the API, if he has no access to the webadmin but only to the user portal, then he should only be allowed to see objects that are exposed in the userPortal (which tags are not available there)
3.2 has been released