Christian G. Warden wrote: > Is there a recommended way of implementing IPermissionPolicy such that > multiple policies don't cause infinite recursion? I'm writing a > simple policy similar to SensitiveTicketsPolicy that requires a new > permission in order to view sensitive components, and I would like to > use it in combination with PrivateTicketsPolicy. > > The problem is evident when enabling SensitiveTicketsPolicy and > PrivateTicketsPolicy. The former checks for the VIEW_SENSITIVE > permission, which causes PrivateTicketsPolicy's check_permission to be > called. PrivateTicketsPolicy, in turn, checks for its permissions, > which causes SensitiveTicketsPolicy's check_permission to be called, > until maximum recursion depth is hit. > > Is there a cleaner solution than having my policy explicitly ignore > the PrivateTicketsPolicy permissions? >
I don't know those plugins, but assuming they're working in a similar way to the vulnerability_tickets.py sample plugin, I tried to imagine a way through. The perm and resource objects are both non-extensible objects (their class is using the __slots__ mechanism), so you can't attach a marker there to indicate that you're re-entering your permission policy. So one way (apart from looking directly through the call stack...) would be to create a Thread.local dictionary (or set) and keep note there of the resources you've already started to check, so that you can avoid recursion. Of course, in future versions of the permission API, we could add a mechanism for avoiding such issues, or at least make it easier for permission policies to detect such situations. -- Christian -- You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en.
