[ZPatterns] thanks and question
Rob Miller
[email protected]
Fri, 11 Oct 2002 11:07:34 -0700
Steve Spicklemire wrote:
> Hi Rob,
>
> Hmm.. I would've expected something more like "permission denied". Can
> you tell us a bit more about the containment hierarchy of these objects?
> (Esp relative to your LoginManager, and the customizer?) Also.. which
> roles have the "Access Contents Information" in the folder that contains
> the to "getMembersWithRole" script?
Sure! Here's the folder structure:
Root Folder
|
|
brcdev
|
|--------------|
| |
acl_users(LM) v03(Folder w/ Cust Support)
| |
| |
UserSource |
|
|-----------------|------------------|
| | |
teamfolder_customizer teamfolder1 teamfolder2
|
|---------|---------------|
| |
getMembersWithRole() teamfolder_data(SkinScript)
I hope this makes sense... my customizer folder is at the same level as
the LoginManager acl_users folder. The 'v03' Customizer Folder contains
the customizer, which in turn contains the TeamFolder's SkinScript and
all of the methods that it relies upon, including the
getMembersWithRole() method on which the process is barfing.
The TeamFolder instances themselves are directly in the v03 folder... it
is while accessing pages within one of these TeamFolders that the error
occurs. I've tried putting the LoginManager folder within the v03
folder, but nothing changed.
The "Access Contents Information" permission is granted to Anonymous and
Manager in the root folder, and this is not overridden in any other
location. I've tried explicitly allowing this permission to all roles,
with no change in the result. I've also gone into my Product folder
where all of the ZClasses live and have explicitly changed all of the
permission mappings such that "Access Contents Information" maps to "View".
I'm familiar with the permissions errors that you're referring to...
this seems different. My best guess is that somehow, during the
authentication process, the acquisition hierarchy for the
AttributeProviders framework that glues the TeamFolders to their
SkinScript attributes hasn't been configured correctly. Maybe it's
because my method is in a Python base class... the acquisition context,
which is usually passed around silently, has been lost somewhere. I'm
not sure, of course, that's just what it looks like.
Here's the exact traceback I get:
---------------------------
<TD WIDTH="90%">
<H2>Site Error</H2>
<P>An error was encountered while publishing this resource.
</P>
<P><STRONG>NameError</STRONG></P>
Sorry, a site error occurred.<p>
<!--
Traceback (innermost last):
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/ZPublisher/Publish.py,
line 150, in publish_module
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/ZPublisher/Publish.py,
line 114, in publish
File /usr/home/zope-havoc/src/zope-havoc/lib/python/Zope/__init__.py,
line 159, in zpublisher_exception_hook
(Object: FrontPage)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/ZPublisher/Publish.py,
line 89, in publish
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/ZPublisher/BaseRequest.py,
line 388, in traverse
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/LoginManager/LoginManager.py,
line 250, in validate
(Object: acl_users)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/LoginManager/LoginManager.py,
line 76, in allowed
(Object: ra)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/LoginManager/LoginManager.py,
line 51, in getRolesInContext
(Object: ra)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/LoginManager/LoginManager.py,
line 27, in get_local_roles_for_user
(Object: extranet)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/BRCPython/BRCFolderBase.py,
line 22, in get_local_roles_for_userid
(Object: extranet)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/ZPatterns/DataSkins.py,
line 215, in __get_attr__
(Object: extranet)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/ZPatterns/AttributeProviders.py,
line 355, in _AttributeFor
(Object: teamfolder_data, line 6)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/ZPatterns/AttributeProviders.py,
line 302, in _AttributeFor
(Object: teamfolder_data, line 6)
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/Products/ZPatterns/Expressions.py,
line 123, in eval
File
/usr/home/zope-havoc/src/zope-havoc/lib/python/DocumentTemplate/DT_Util.py,
line 159, in eval
(Object: getMembersWithRole ( team_id = self . team_id ,
team_role_id = 1 ))
(Info: self)
File <string>, line 2, in f
NameError: global name 'getMembersWithRole' is not defined
-----------------------------
Thanks for you time!
-r
>
> On Friday, October 11, 2002, at 01:39 AM, Rob Miller wrote:
>
>> hi all,
>>
>> i just stumbled across this list and have read the last couple of
>> month's archives. what a nice surprise! thanks, roche, for your new
>> documentation and releases. i very much support seeing all the
>> existing code put into cvs. i've been digging pretty deeply into
>> things lately since i'm using zpatterns and loginmanager as the basis
>> for a sizable project. i would love to be able to make improvements
>> to the framework and to submit them to an active project for
>> everyone's benefit. i've already submitted a patch to casey, author
>> of externaleditor, so that the external editor icons will show up
>> correctly within folders w/ customizer support; i'm hoping he includes
>> it in his next release.
>>
>> anyway, the reason i sought out this list is because i have a fairly
>> low-level problem that i'm hoping someone can help me with. here's the
>> sitch:
>>
>> i've got two dataskin zclasses, one called BRCMember and one called
>> TeamFolder. they each have a python base class that i've created (in a
>> filesystem product), called BRCMemberBase and TeamFolderBase,
>> respectively. BRCMemberBase subclasses LoginManager's LoginUser,
>> TeamFolderBase subclasses both DataSkin and the regular zope Folder
>> object, like so:
>>
>> in the TeamFolderBase class, i have a 'get_local_roles_for_userid'
>> method. this method overrides (and extends) RoleManager's
>> 'get_local_roles_for_userid' method, which, i believe, zope calls when
>> checking security for every page access. my version of this method
>> looks like this:
>>
>>
>> def get_local_roles_for_userid(self, userid, roles=()):
>> # as near as i can tell the 'roles' argument does nothing... see
>> # Products/LoginManager/LoginManager.py and AccessControl/Role.py
>> retlist = Folder.get_local_roles_for_userid(self, userid, roles)
>> if userid in self.member_list: #<--- THIS IS THE TROUBLE
>> retlist.append('member')
>> return retlist
>>
>>
>> i've marked the problem spot... the member_list attribute is a
>> zpatterns attribute... the data comes from a skinscript that lives in
>> a TeamFolder customizer containing the following line:
>>
>>
>> WITH getMembersWithRole(team_id=self.team_id, team_role_id=1)
>> COMPUTE member_list = RESULT
>>
>>
>> 'getMembersWithRole' is a python script that lives in the customizer
>> itself. normally, it works fine; i access the 'member_list' attribute
>> from within my pages frequently. whenever my local roles code gets
>> called at authentication time, though, the zpatterns plumbing breaks
>> down, and I get the following:
>>
>>
>> Error Type: NameError
>> Error Value: global name 'getMembersWithRole' is not defined
>>
>>
>> the traceback shows that the zpatterns AttributeProviders mechanism is
>> kicking in appropriately. it seems as though the skinscript's
>> acquisition hierarchy has broken down, or something.
>>
>> one important point is that using 'user.has_permission()' in a ZPT or
>> a dtml page _does_ work... the local roles are enforced as expected.
>> it's only when this code gets executed during the page authentication
>> that the problem occurs.
>>
>> does anybody know why this might be happening? if not, i'd settle for
>> a workaround: has anyone using ZPatterns and LoginManager successfully
>> gotten local roles information to come out of a SQL database using
>> another method?
>>
>> thanks!
>>
>> -r
>>
>> _______________________________________________
>> ZPatterns mailing list
>> [email protected]
>> http://www.eby-sarna.com/mailman/listinfo/zpatterns
>
>