On May 18, 2012, at 3:33 PM, Cédric Krier wrote: > I see two solutions to this issue: > > - Using the root context switching in the code everywhere it is > needed based on the default access right define in Tryton. > This means the developper must take care of this everytime he > write code. This is a little bit constraining but it has the > advantage to execute the smaller part of the code as root.
+1 seems like the best thing to do.
>
> - Remove the access right from within the CRUD to move it just on
> the rpc calls and run all the code as root.
> This has the advantage to be simple but it is a bad design for
> security principle to run the least possible code as root.
I think limiting security to RPC (i think that implementation will
be at the dispatcher level), will be bad for projects which use
tryton as a module. They will need to reimplement the same thing
over and over.
However, your suggestion brings us to a whole new way
in which we could probably enforce access control logic. At the
moment we defined ACL on groups and the membership of the user
to these groups define the rights of the user. While, retaining this
behavior we could switch the CRUD definitions also to python code
like what we did with Workflow transitions (From xml through database
to Python code).
Eg:
@Model.user_in_group(['sale.sale', 'product.product_admin'])
def create(self, vals):
do create only if the user has permissions
This will allow us to reuse the same decorator for steps in workflow
as well like:
@Model.user_in_group(['sale.sale_manager'])
@ModelView.button
@Workflow.transition('confirmed')
def confirm_without_credit_check(self, ids):
pass
Thanks
Sharoon Thomas
Openlabs Technologies & Consulting (P) Limited
w: http://www.openlabs.co.in
t: @sharoonthomas
- We CARE for our customers
signature.asc
Description: Message signed with OpenPGP using GPGMail
