Bug 857018 - rhevm-sdk: make /filter header global rather than method driven
rhevm-sdk: make /filter header global rather than method driven
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
3.1.0
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Michael Pasternak
Ondra Machacek
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-13 07:56 EDT by Ondra Machacek
Modified: 2016-02-10 14:32 EST (History)
13 users (show)

See Also:
Fixed In Version: si20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 14:59:35 EST
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 Ondra Machacek 2012-09-13 07:56:45 EDT
Description of problem:
same problem as https://bugzilla.redhat.com/show_bug.cgi?id=854296 for other permissions.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

IMHO header 'Filter: {value: true|false, required: false}' should be also for?

-- TemplateOwner permissions --
/api/templates/{template:id}|rel=delete
/api/templates/{template:id}|rel=update
/api/templates|rel=add

-- DiskOperator permissions --
/api/templates/*|rel=*

-- vmpool operations(PowerUserRole) --
/api/vmpools/*|rel=*
Comment 1 Oded Ramraz 2012-09-13 15:54:36 EDT
Ondrej , please explain which operations you are trying to perform and the list of  
permissions your users has .
Comment 2 Oded Ramraz 2012-09-13 15:56:59 EDT
It looks like API related issue , please change bug component if needed .
Comment 3 Ondra Machacek 2012-09-13 17:40:32 EDT
I think it is same issues as bz 854296, because everything works for me with via REST API.

Some things I tryied:
1) Add user with "TemplateOwner" role on DC.
2) Try to run code below.

code(version of ovirtsdk is 3.2.0.1):

API = ovirtsdk.api.API(
                    url='https://url:443/api', insecure=True,
                    username='newUser',
                    password='password', filter=True)
vm = API.vms.get(name='vmName')
API.templates.add(params.Template(name='templateName', vm=vm)) # Fails
# same for template.nics.add(params.NIC())
# same for API.templates.get(templateName).delete()

Getting an error:
query execution failed due to insufficient permissions.

This error is getting also via REST API if i use curl and don't use "Filter: true" header. 

After some playing around i think 'filter' header is missing in all permission which are the same for Admin roles and user roles. That are all permissions which has these roles:
TemplateOwner, DiskCreator, TemplateCreator, VmCreator, DiskOperator, UserVmManager, PowerUserRole, UserRole.
Comment 4 Oved Ourfali 2012-09-16 04:52:02 EDT
Michael - are there operations that we shouldn't pass the filter header to?
If the answer is no, shouldn't we somehow use the filter header definition (Filter: {value: true|false, required: false}) only in one place, making all the actions inherit it?
Comment 5 Michael Pasternak 2012-09-16 14:18:55 EDT
(In reply to comment #4)
> Michael - are there operations that we shouldn't pass the filter header to?

good question, asaf?

> If the answer is no, shouldn't we somehow use the filter header definition
> (Filter: {value: true|false, required: false}) only in one place, making all
> the actions inherit it?

it's doable, worth case, api will ignore it
Comment 6 Michael Pasternak 2012-09-19 09:44:05 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > Michael - are there operations that we shouldn't pass the filter header to?
> 
> good question, asaf?
> 
> > If the answer is no, shouldn't we somehow use the filter header definition
> > (Filter: {value: true|false, required: false}) only in one place, making all
> > the actions inherit it?
> 
> it's doable, worth case, api will ignore it

ok, before we decide on making global filter=x, is there a use-case
that admin user would like to run method X as filtered=true and method
Y as filtered=false?
Comment 7 Michael Pasternak 2012-09-20 02:20:17 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Michael - are there operations that we shouldn't pass the filter header to?
> > 
> > good question, asaf?
> > 
> > > If the answer is no, shouldn't we somehow use the filter header definition
> > > (Filter: {value: true|false, required: false}) only in one place, making all
> > > the actions inherit it?
> > 
> > it's doable, worth case, api will ignore it
> 
> ok, before we decide on making global filter=x, is there a use-case
> that admin user would like to run method X as filtered=true and method
> Y as filtered=false?

mention functionality can be achieved via: api.set_filter(true|false)
between method invocations 


rhevm-sdk: make /filter header global rather than method driven
Comment 8 Itamar Heim 2012-09-20 05:42:27 EDT
we can wait for that use case to happen.
but, iirc, there is planned work on handling multiple connections to different ovirt engines.
that would mean diffrenet credentials to different engines.
it would also mean for each connection different filter mode.
so i'd argue filter mode can be a connection level property.
and sdk should allow working with two connections to same engine, one filtered, and one not.

actually, in a connection broker (user portal) implementation, i'd expect the code to keep a connection per user to same engine (and use filtred mode for all).

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