Bug 869332 - /api (api entry point) should be accessible for all users
/api (api entry point) should be accessible for all users
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Michael Pasternak
Oded Ramraz
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-23 11:28 EDT by David Jaša
Modified: 2016-02-10 14:06 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-24 04:16:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-10-23 11:28:41 EDT
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@example.com ... 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 11:59:40 EDT
non-admin users should raise -filter flag, did you used it?
Comment 2 Michael Pasternak 2012-10-24 04:16:21 EDT
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 14:29:45 EST
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.