On Thu, Jun 14, 2012 at 7:17 AM, Chris McDonough <[email protected]> wrote:
> On 06/14/2012 09:55 AM, Przemyslaw Wegrzyn wrote: > >> >> Well, I know that authors are not happy with overall design, as >> explained here >> http://plope.com/pyramid_auth_**design_api_postmortem<http://plope.com/pyramid_auth_design_api_postmortem>(and >> I have to say I agree with this post 100%), but principals idea is there >> anyway, so why not make it more efficient? >> > > Becase, eventually, someone will need to clear the cache when the list of > effective principals changes as the result of something happening during a > request, such as the current user obtaining a new group or losing a group. > Since the way principals are computed is application-specific, the > framework itself can't know when this happens, and so it can't clear any > cache automatically. And rather than violating rule of least surprise wrt > the freshness of the list of effective principals and a framework-level > cache, we leave it up to the application to do the caching and clearing of > that cache. > > But as noted by that post, the groupfinder abstraction is dumb. People > should just create a new authentication policy or subclass an existing > policy. When you do this, there's a natural place to add caching. One of Pyramid's selling points is its built-in authorization. Pylons never had that, which required me to write my own in one application or use repoze.who/what. My own system works but is non-scalable: I punted on multiple groups and just allowed one group per user, so we have to put users in less-than-ideal groups to avoid the number of groups becoming n = (number of permissions)! Repoze.who/what are WSGI-based so they're more complicated/cumbersome than they have to be (and they didn't exist when I wrote mine). So application developers definitely prefer a framework-supported authorization system. I've watched the Pyramid auth debates from a distance since my application is still in Pylons. But when I do port it to Pyramid, the issue will come up whether to fully use the auth API or do something different. Parts of the auth API do seem a little cumbersome. Yet if I make something else, I'd want it to be reusable if possible. So, would it be possible to implement the alternate API as an add-on or tween, bypassing the built-in system or making a compatibility stub to it? Or would the built-in system get in the way too much for that to be feasable? -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
