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

2005-09-19 Thread 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 = uText Content,
   description = uSome 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 = uapple
   
   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 [EMAIL PROTECTED] 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@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/dominik.huber%40perse.ch




begin:vcard
fn:Dominik Huber
n:Huber;Dominik
email;internet:[EMAIL PROTECTED]
tel;work:++41 56 534 77 30
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



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

2005-09-18 Thread Alec Munro
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 = uText Content,
description = uSome 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 = uapple

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 [EMAIL PROTECTED] 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@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com