2012 m. gegužė 18 d., penktadienis 17:36:52 UTC+3, Sharoon Thomas rašė:
>
>
> 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.
>
>
It is more elegant solution than switching context, but it won't work on
current cumbersome design of Tryton. The main problem of current
design is that there is no separation between controller (interface for
objects dispatch) and model (data structure, application state). I see
some work is made in right direction by implementing Active record
pattern on models. So now (if i'm not wrong) @classmethod represents
controller while other methods are used for changing state of Active
Record instance. By having this design we can go further by declaring
that access rights should never go on model level, its place is in
controller level. Also we must make sure that dispatched method
is never called by another dispatched method.
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.
>
>
It's even better. You can use data model without any security and
integrate them with different security system. Or if you don't want to
do this, you can use dispatched methods from Tryton itself.
> 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
>
>
It's generally bad idea to use xml IDs in python code. But we need
something if we going to allow security not only on 4 dispatched
methods (CRUD). The number of dispatched methods (RPC calls) is
indeterminate. It could be implemented like this:
class SaleOrder(...):
__name__ = 'sale.order'
@Permission.need('create', 'process')
@classmethod
def do_something_fancy(self, ids):
pass
Groups is described in xml file with provided permissions.
sales_manager_group = {
'sale.order': ['create', 'process', 'delete', 'confirm', 'update',
'read', 'search']
}
--
[email protected] mailing list
