On Jun 20, 2012, at 9:44 PM, Chris McDonough wrote: > > In other words, it's Pyramid's job to figure out whether the current user can > execute the view based on the ACL. If the ACL is computed based on who is > logged in, things get weird pretty fast... it's just a divide by zero error > sort of, and it'd be a better idea to implement a custom authorization policy > if you want to think of things that way.
here's whats not clear about Pyramid, and had to be illustrated for me by an expert. In order to compute the "principals" themselves, based on the current user as well as database data associated with *the user*, you either need to write your own AuthenticationPolicy, and do it in effective_principals, or use that "callback" argument accepted by the provided AuthenticationPolicy. The Pyramid docs make it very easy to see the example of the context with __acl__ and the dynamic logic inside of it, but then it's not at all clear about adding dynamic rules to authentication policies. It makes the impression to me, as I also saw in some of the examples I was shown on IRC, that the __acl__ hook is "the place where we do any kind of database manipulation of security info for some request". When really, even though that "works" perfectly fine, there are really *two* hooks that the user has to be aware of: 1. the __acl__ is where it is appropriate to do database lookups based on the *resource being requested* 2. the authenticationpolicy custom class or callback is where it is appropriate to do database lookups based on the *user logged in* This dichotomy should be present any time either of the two sides of the coin are discussed. It leads to confusion (at least for me) that dynamic __acl__'s are stressed as a means to apply dynamic rules to resources, but there's not really much mention of what the correct means to apply dynamic rules to principals. Keeping in mind that when mere mortals read documentation, you can't depend on correct terminology alone implanting the right idea, as a newbie doesn't have strong neural pathways and automatic recognition of new terms. You need to break out the hand puppets, even for me. Additionally, another concept that I've had trouble with, since I am not using traversal/zodb, is: 3. pyramid is organized around the idea that a web request is looking at *one thing at a time*. That's why there's a "context". You aren't allowed to make "context" into whatever you want (such as when I just made it into a "security token"). It is meant to correspond to the *thing you are looking at*. Pyramid is more opinionated than I initially expected here. 4. If the thing you are looking at is not actually a *single thing*, and is actually *many things*, such as any kind of search result, listing of information, list of articles, word cloud, or especially a composed page with lots of heterogeneous elements (see http://www.mlb.com for an example of this), Pyramid gives you two choices: a. invent *one thing* that represents that collection. When using traversal/zodb, this is perfectly natural. When using relational databases and routes, it's often completely awkward and artificial, since you're essentially making yourself a fake model object, just so you have a place to stick __acl__ . b. invent some other system. I know the context is discussed quite a bit in "url dispatch" and "security". But I think the docs have a hard job here, as the "context" is already a little bit of a bolted-on concept when you're dealing with routes. When we use routes, we often tend to think of the *view* as the thing that is protected, not the *model*. We want to put security stuff on our views in day-to-day, simplistic cases. Such as, "only users with a certain permission can access the administration pages". How I need to come up with "model-like" objects that have __acl__ but really have nothing to do with my actual "model" I've found to be quite awkward to get my head around. I hit a lot of conceptual dissonance on the IRC channel as Pyramid veterans seem to really see model-level security as something quite natural (and then they say, "because I use traversal and zodb where there's always a single model object anyway"). Model-level security isn't something I get involved in unless I'm building some very fine-grained and elaborate system - usually those end up being hierarchical management types of things which brings us back to traversal/zodb as a strong force here. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
