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 trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to