[Zope3-dev] Re: SVN: Zope3/branches/ctheune-issue-574/src/zope/app/session/configure.zcml - Removed conflicting security declaration for the traversal adapter that

[Philipp von Weitershausen]

Jim Fulton wrote:
> 
> On Aug 10, 2006, at 8:33 AM, Christian Theune wrote:
> 
>> Philipp von Weitershausen wrote:
>>> Christian Theune wrote:
>>>> Log message for revision 69387:
>>>>    - Removed conflicting security declaration for the traversal
>>>> adapter that
>>>>      returns a Session object.
>>>>
>>>> Changed:
>>>>   U  
>>>> Zope3/branches/ctheune-issue-574/src/zope/app/session/configure.zcml
>>>>
>>>> -=-
>>>> Modified:
>>>> Zope3/branches/ctheune-issue-574/src/zope/app/session/configure.zcml
>>>> ===================================================================
>>>> ---
>>>> Zope3/branches/ctheune-issue-574/src/zope/app/session/configure.zcml   
>>>> 2006-08-10 08:24:12 UTC (rev 69386)
>>>> +++
>>>> Zope3/branches/ctheune-issue-574/src/zope/app/session/configure.zcml   
>>>> 2006-08-10 12:23:22 UTC (rev 69387)
>>>> @@ -23,7 +23,6 @@
>>>>        provides="zope.traversing.interfaces.IPathAdapter"
>>>>        factory=".session.Session"
>>>>        name="session"
>>>> -      permission="zope.Public"
>>>>        />
>>>>     <class class=".session.Session">
>>> Hah! I can't believe that was the problem. It all makes sense now. I
>>> still wonder why the session object was still wrapped in a proxy whose
>>> checker didn't allow anything...
> 
> Because IPathAdapter doesn't define any names, so the checker derived from
> it doesn't allow any access.

Gotcha.

>>> Perhaps the system shouldn't
>>> allow such combinations (adapter security + security of the class)?
>>
>> I agree. This combination should raise a ConflictError IMHO.
> 
> I don't agree.  It is reasonable to me that different adapters derived
> from the same class could need different permission settings.

True. Thinking about this now, I agree that there shouldn't be any
ConflictError. The <class> security declaration and the <adapter>
security declaration are pretty different. <adapter> makes sure the
object gets a special checker that only allows the attributes of the
provided interface, <class> just defines what a checker WOULD check if
the object was wrapped through a ProxyFactory.

As Theuni said, we were doing both which led to the unexpected
behaviour. Normally you wouldn't do both, though...

Philipp