On Wednesday, September 21, 2016 at 11:12:43 AM UTC-7, Peter Suter wrote: > > On 21.09.2016 09:06, Florian Schricker wrote: > > Unfortunately it still fails. > > This time I am attaching a more or less complete log from tracd-start > until "recursion error" and the source file of the plugin I am using. > > I hope that helps - I am more than willing in testing anything while > providing any information I can collect. Any config files or other files of > interest? Just let me know. > > regards, > Florian > > Am Freitag, 16. September 2016 03:16:17 UTC+2 schrieb RjOllos: >> >> On Tuesday, August 30, 2016 at 12:25:26 AM UTC-7, Florian Schricker >> wrote: >>> >>> While this now fixes the Timeline function, modifying tickets now fails >>> with the same recursion error. I have not yet checked the logs. >>> >>> For a better understanding let me ask the following question: >>> >>> From my research I was not expecting the policies to "interact" with >>> each other recursively at all. I was thinking that all configured policies >>> are asked in sequence until some policy returns True or False, with >>> returning None just meaning "ask the next policy". Where is the recursion? >>> Is it a bug in TracPrivateTickets? >>> >> > It's "mutual recursion". Unfortunately that means it's not a simple bug > you can necessarily fix in one plugin alone. It's an unfortunate > interaction between the two plugins. > The idea was, exactly as you say, to ask each policy in turn. But each > plugin basically says: "Hang on, before I answer, let me ask you this > first: Is this other thing allowed?" > And again each policy is asked in turn about this new question, and so on > forever... > > Each policy is protected against its own such recursive questions: > > Am Freitag, 16. September 2016 03:16:17 UTC+2 schrieb RjOllos: > > There shouldn't be recursion in ReadonlySignedTickets because of the check >> "action == 'TICKET_ADMIN' or 'TICKET_ADMIN' in perm". "'TICKET_ADMIN' in >> perm" will cause a recursive permission check for the action TICKET_ADMIN, >> but when ReadonlySignedTickets is called again it will return None due to >> the "action == 'TICKET_ADMIN'" conditional. >> > But neither policy can detect re-entrancy in general. It only shortcuts > its own kind of followup question. > Since the other policy asks about a different kind of permission, this is > not detected. >
Based on what you said, I considered if we could detect re-entrancy by passing the policy to the permission cache when doing a PermissionCache.has_permission check inside of PermissionCache.check_permission: https://trac.edgewall.org/ticket/12597 The changes might need some additional work, but it seems to work with: permission_policies = ReadonlySignedTickets, PrivateTicketsPolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy I expect other permission policies such as PrivateTicketsPlugin would need to be modified in the way proposed for SignedTicketsPolicy. I also posted modifications to SignedTickets, but I don't expect they will fix this "interaction" issue: https://trac.edgewall.org/wiki/CookBook/Configuration/SignedTickets?version=9 - Ryan -- You received this message because you are subscribed to the Google Groups "Trac Users" 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]. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
