[Zope3-dev] Re: Security mechanism finds permissions for Built-in principals, but not custom principals.

[Dominik Huber]

Hi Alec

Your derivative of principalfolder is a local authentication. Therefore it can be only invoked if a location can be computed and the pricipalfolder can be found starting from it.

Content objects are regularly locatable but adapters not. To force locations to adapters you can derive them from Location or set the adapter-directive-attribute `locate` to True, that they get location-proxied if necessary.

Regards,
Dominik



Alec Munro wrote:

>Well, it's gotten worse.
>
>I've been trying to narrow this down, and so far, haven't come up with
>anything promising. I'm now using the built in principal folder, and
>the associated principals, not ones of my own. My current failing test
>case boils down to:
>
>interfaces.py
>============
>
>from zope.interface import Interface
>from zope.schema import TextLine
>
>from zope.app.annotation.interfaces import IAnnotatable
>
>class ISomeContent(Interface):
>    
>    text_content = TextLine(
>        title = u"Text Content",
>        description = u"Some Text Content for testing")
>        
>class ISomeContentAttributable(IAnnotatable):
>    """An object that can contain some content"""
>
>configure.zcml
>===============
>
><configure xmlns="http://namespaces.zope.org/zope"
>           xmlns:browser="http://namespaces.zope.org/browser">
>
><content class="zope.app.file.file.File">
>  <implements
>      interface="zope.app.annotation.interfaces.IAttributeAnnotatable
>                 .interfaces.ISomeContentAttributable"
>      />            
></content>
>           
><adapter
>    for=".interfaces.ISomeContentAttributable"
>    provides=".interfaces.ISomeContent"
>    factory=".somecontent.SomeContent"
>    trusted="true"
>    />
>
><content class=".somecontent.SomeContent">
>  <require
>      permission="myproject.View"
>      interface=".interfaces.ISomeContent"
>      />
>  <require
>      permission="zope.View"
>      set_schema=".interfaces.ISomeContent"
>      />
></content>
>          
><browser:editform
>    for=".interfaces.ISomeContentAttributable"
>    schema=".interfaces.ISomeContent"
>    label="Some Content"
>    name="content.html"
>    menu="zmi_views" title="Some Content"
>    permission="zope.View"
>    />
>           
></configure>
>
>somecontent.py
>=================
>from zope.interface import implements
>from interfaces import ISomeContent
>
>KEY = "somecontent.perm_tests"
>
>class SomeContent(object):
>    implements(ISomeContent)
>    
>    text_content = u"apple"
>    
>    def __init__(self, context):
>        self.context = context
>
>
>
>So there's the code, if I change myproject.View to zope.View,
>everything works. I can grant myproject.View on the object itself, to
>the appropriate principal, and I will get an Unauthorized error. Yet
>if I change it to zope.View, it works.
>
>Any ideas?
>
>Thanks,
>
>Alec munro
>
>On 9/16/05, Alec Munro <alecmunro at gmail.com> wrote:
>
>>Hi All,
>>
>>I have created my own principal source, as a bare derivative of principalfolder.
>>My principals can log in, and are generally effective.
>>
>>
>>However, there seems to be some lacking to them. Whenever I access any
>>of a certain bunch of annotation adapters, I get a silent abort. That
>>is, it prints abort on the command line, but no more information. My
>>own personal experience is that these tend to be permission errors, so
>>I assume it is something like that.
>>
>>What is especially odd is that I can assign the required permission to
>>zope.anybody, and I am able to access the adapters. Doing a heavy
>>sequence of print-based debugging, I found out that the error seems to
>>occur during a sequence of calls to my adapters __getattr__ method.
>>This method, in the case of my adapters, looks up the key in a
>>mapping, and raises an attribute error if it is not there. In each
>>case, the error occurs after it looks for a number of keys that aren't
>>there, a long sequence of "__parent__", and "__conform__". These occur
>>when I attempt to access a property of the adapter (any property).
>>They also occur even when it works, such as if I'm using zope.anybody,
>>so I don't think it is the calls themself that are causing there
>>error.
>>
>>My impression is that the calls are related to zopes security
>>machinery, and that for some reason they end up being executed in a
>>place where they are unable to find the correct principal.
>>
>>I'm sure you need more information, but I'm not sure what would be helpful.
>>
>>Thanks,
>>
>>Alec Munro
>>
>>
>_______________________________________________
>Zope3-dev mailing list
>Zope3-dev at zope.org
>Unsub: http://mail.zope.org/mailman/options/zope3-dev/dominik.huber%40perse.ch
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dominik.huber.vcf
Type: text/x-vcard
Size: 154 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20050919/034717e1/dominik.huber.vcf