Proper handling of views for ACL roles

[jens.t...@gmail.com]

Hi,

I'm using Cornice and Pyramid for my REST API server, and followed the standard authorization examples using ACLs. For example:

# The Cornice service.

bills_service = Service("bills", "/api/bills", factory=BillsListContext)

# The Context factory:

class BillListContext(object):

    def __init__(self, request):

        pass

    @property

    def __acl__(self):

        return [

            (Allow, "role:buyer", "get_bills"),

            (Allow, "role:seller", "get_bills"),

        ]

# And the view function is then:

@bills_service.get(

    content_type="application/json",

    accept="application/json",

    permission="get_bills",

    )

def get_bills(request):

    # …

The view implementation now contains role checks (if request.user.role...) and services requests depending on the requesting user's role. 

My question is: is there a better way to implement views for different roles? How would I decorate view functions, each for a specified role? What is the recommended way here?

Thanks!

[Michael Merickel]

It seems you're asking about how to affect the "view lookup" [1] phase of the request.

https://docs.pylonsproject.org/projects/pyramid/en/1.9-branch/narr/router.html

The "permission=" is not a predicate and thus cannot be used as part of view lookup to select between various views. The way to do what you're asking (assuming that your role-based principals are mutually exclusive) is to use the "effective_principals=[some_role]" predicate which *will* allow view lookup to continue until a view that matches is found. The reason I say they must be mutually exclusive is that view lookup is effectively unordered and thus values for a predicate are expected to be tested without respect to other registered views with similar predicates.

- Michael

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/605159f6-1461-4dd4-b133-88d7f0748795%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jens.t...@gmail.com]

Thank you, Michael, exactly what I was looking for :-)

I understand your point of mutually exclusive roles for predicates, but seeing that `effective_principals` takes a list, I assume that I can use multiple roles for the predicate?

Cheers,

Jens

To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.

[Michael Merickel]

> I understand your point of mutually exclusive roles for predicates, but seeing that `effective_principals` takes a list, I assume that I can use multiple roles for the predicate?

Right, my point there is that sometimes it's by design in how the predicates work and sometimes it's on you as a user to be super careful. For example, the "xhr" predicate is by-design unambiguous. It takes only True/False or unspecified, so you can't pass to two separate views a value=A and value=B where A is a subset of B. However, in the case of effective_principals you *can* pass ambiguous values to two views - so you need to be aware of that and be careful what you choose to do. For example effective_principals=[Authenticated] versus [Everyone] is *not* mutually exclusive and could bite you based on the other the views are tested (which should be assumed random) because usually if you are Authenticated then you also are Everyone so if the Everyone view is tested first then no one will ever go to the Authenticated view. You'd be better off using [Authenticated] on one view and not defining at all the effective_principals predicate on the other view (basically claiming you'll take anything that didn't pass the predicate on the other view).

Anyway it's a long-winded way of saying that effective_principals works well if your roles do not overlap. If you suffer from such problems then relying on predicates alone may not be enough for you and you'll need to do your own dispatch in the view itself. For example "if (foo) then call viewA elif (bar) then call viewB else call viewC" which is not something you can do easily with predicates. You can, but only by defining separate predicates with ordering between them which is a lot for most people to consider.

- Michael

To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscribe@googlegroups.com.

To post to this group, send email to pylons-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/88898120-47dd-4333-a688-f8cc0ce843dd%40googlegroups.com.