> 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 On Mon, Oct 16, 2017 at 6:59 PM, <[email protected]> wrote: > 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 > > > On Monday, October 16, 2017 at 11:04:56 AM UTC+10, Michael Merickel wrote: >> >> 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-branc >> h/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 >> >> On Sun, Oct 15, 2017 at 6:51 PM, <[email protected]> wrote: >> >>> Hi, >>> >>> I'm using Cornice <https://github.com/Cornices/cornice> and Pyramid >>> <https://github.com/Pylons/pyramid> for my REST API server, and >>> followed the standard authorization examples using ACLs >>> <https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/security.html#assigning-acls-to-your-resource-objects>. >>> 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! >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/pylons-discuss/605159f6-1461-4dd4-b133-88d7f0748795%40go >>> oglegroups.com >>> <https://groups.google.com/d/msgid/pylons-discuss/605159f6-1461-4dd4-b133-88d7f0748795%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/pylons-discuss/88898120-47dd-4333-a688-f8cc0ce843dd%40googlegroups.com > <https://groups.google.com/d/msgid/pylons-discuss/88898120-47dd-4333-a688-f8cc0ce843dd%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAKdhhwFBXKVqPexTr2xSrWEA8SAHtGD5uJaM9NmktCRLUCrfxg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
