Bug 869332 - /api (api entry point) should be accessible for all users
Summary: /api (api entry point) should be accessible for all users
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Michael Pasternak
QA Contact: Oded Ramraz
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-23 15:28 UTC by David Jaša
Modified: 2016-02-10 19:06 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-24 08:16:21 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description David Jaša 2012-10-23 15:28:41 UTC
Description of problem:
/api (api entry point) should be accessible for all users if they successfully authenticate. This bug makes rhevm-cli unusable for non-admin users.

Version-Release number of selected component (if applicable):
3.1.0-18 / si19.1

How reproducible:
always

Steps to Reproduce:
1. curl -u regular_user ... https://rhevm.example.com/api
2.
3.
  
Actual results:
400 bad request
<fault>
    <reason>Operation Failed</reason>
    <detail>query execution failed due to insufficient permissions.</detail>
</fault>

Expected results:
200 OK
...

Additional info:

Comment 1 Michael Pasternak 2012-10-23 15:59:40 UTC
non-admin users should raise -filter flag, did you used it?

Comment 2 Michael Pasternak 2012-10-24 08:16:21 UTC
David,

from your curl example i see that you did not passed /filter header
what is required for non-admin users for being served, also afaik
this use-case has been tested by ondra, so i'm closing this bug,
- reopen it if you have other findings.

Comment 3 David Jaša 2012-11-08 19:29:45 UTC
in si24, the /api is accessible for plain users when "filter: true" is set.

I didn't test the cli (and I don't have access to the setup atm), the second use case for this behaviour I envisioned was to have a single point that app accessing filtered results can GET to get authentication cookie without unnecessary load on the server.


Note You need to log in before you can comment on or make changes to this bug.