[Users] Authentication for REST APIs?

[Itamar Heim]

On 10/02/2012 03:56 PM, Steve Gordon wrote:
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Brian Vetter" <bjvetter at gmail.com>
>> Cc: users at ovirt.org
>> Sent: Tuesday, October 2, 2012 3:15:34 AM
>> Subject: Re: [Users] Authentication for REST APIs?
>>
>> On 10/02/2012 06:28 AM, Brian Vetter wrote:
>>> I've done two different things. First, I associated one of my
>>> groups in my directory with being a VMUser which gave members
>>> access to a particular VM. If I login with one of those users via
>>> the User portal, I can see their VM (or VMs if I do more than
>>> one). If I use the REST API (or ovirt-shell) using this user's
>>> account and password, I get an unauthorized error.
>>>
>>> Similarly, I have another group that is assigned the DomainManager
>>> role. If I add this other user to that group, when I login with
>>> that user via the user portal, I see the advanced portal. If I use
>>> the REST-API (using curl) or ovirt-shell and use the user's login
>>> information, I now am authorized and see a list of VMs returned as
>>> XML (in the case of curl).
>>>
>>> That said, I see all VMs in the system, not just the one assigned
>>> to the user that logged in. So this makes me think that either the
>>> REST API for getting the APIs as suggested by the article is an
>>> administrative API and there is either (a) a different rest
>>> API/uri that returns the logged in user's vms (the list that would
>>> be returned to the portal) or (b) no way to get a particular
>>> user's list of VMs authenticated as the user.
>>
>> you need to specify to the api you want to view things in "user mode"
>> via the filter header.
>> Example:
>> curl -X GET -H "Filter: true" -u user at domain:password
>> http://[servername]:PORT/api/vms
>
> Yes, and if using the SDK set filter=true when calling the API constructor (is there a reason filtered isn't the default? Wouldn't this suit both uses - admin/non-admin - better?).
>
> Steve
>

I think only reason is the api had admin by default in 3.0, so to 
preserve functionality