PROBLEM(100) Init Ambiguous name
Hi Shane, I'm seeing this with Squishdot on Zope 2.4.0:
2001-07-24T16:42:28 PROBLEM(100) Init Ambiguous name for method of Products.Squi shdot.Posting.Posting: "manage_editForm" != "manage_main"
I saw you answer a question about this with another product, and I was wondering what you recommend I do to fix the problem. The offending line looks line in Posting.py looks like: manage_main = manage_editForm cheers, Chris
On Friday 27 July 2001 11:20, Chris Withers wrote:
Hi Shane,
I'm seeing this with Squishdot on Zope 2.4.0:
2001-07-24T16:42:28 PROBLEM(100) Init Ambiguous name for method of Products.Squi shdot.Posting.Posting: "manage_editForm" != "manage_main"
I saw you answer a question about this with another product, and I was wondering what you recommend I do to fix the problem.
The offending line looks line in Posting.py looks like:
manage_main = manage_editForm
Either manage_main or manage_editForm is protected by a permission, right? Whichever it is, that's the "official" name for the method. Assuming it's "manage_editForm", you would add a line like this below the line you quoted: manage_editForm._setName("manage_editForm") That way there's no ambiguity. Shane
Shane Hathaway wrote:
<snip>
manage_main = manage_editForm
Assuming it's "manage_editForm", you would add a line like this below the line you quoted:
manage_editForm._setName("manage_editForm")
Ah, okay, is it 'okay' to use _setName in the longterm?
Either manage_main or manage_editForm is protected by a permission, right?
Yupe, they both are, I think.
Whichever it is, that's the "official" name for the method.
What happens if I want to protect manage_editForm with one permission and manage_main with another? Also, kindof related, what happens if I want to protect a method with more than one permission? cheers, Chris
On Friday 27 July 2001 12:06, Chris Withers wrote:
Shane Hathaway wrote:
<snip>
manage_main = manage_editForm
Assuming it's "manage_editForm", you would add a line like this below the line you quoted:
manage_editForm._setName("manage_editForm")
Ah, okay, is it 'okay' to use _setName in the longterm?
Yes.
What happens if I want to protect manage_editForm with one permission and manage_main with another?
You can't. :-) That's why the ambiguity is a problem. If the method is called manage_editForm, the security machinery (under most circumstance) will look for "manage_editForm__roles__" no matter what attribute name you used to access it. Maybe someday this will change.
Also, kindof related, what happens if I want to protect a method with more than one permission?
You can't do that either, and for good reason. Would it be an OR or an AND operation? Or some combination? Better to just call getSecurityManager().checkPermission(). Shane
Shane Hathaway wrote:
What happens if I want to protect manage_editForm with one permission and manage_main with another?
You can't. :-) That's why the ambiguity is a problem. If the method is called manage_editForm, the security machinery (under most circumstance) will look for "manage_editForm__roles__" no matter what attribute name you used to access it. Maybe someday this will change.
Also, kindof related, what happens if I want to protect a method with more than one permission?
You can't do that either, and for good reason. Would it be an OR or an AND operation? Or some combination? Better to just call getSecurityManager().checkPermission().
Thanks :-) How do we make sure both of these are documented in big flashing letters in the development guide? I've been at the python product programming thang for some time (;-) now and I never knew that, in fact I had made completely incorrect assumptions... cheers, Chris
Shane
If someone summarizes the distinctions made in this email, I can put it in the ZDG. Chris Withers wrote:
Shane Hathaway wrote:
What happens if I want to protect manage_editForm with one permission and manage_main with another?
You can't. :-) That's why the ambiguity is a problem. If the method is called manage_editForm, the security machinery (under most circumstance) will look for "manage_editForm__roles__" no matter what attribute name you used to access it. Maybe someday this will change.
Also, kindof related, what happens if I want to protect a method with more than one permission?
You can't do that either, and for good reason. Would it be an OR or an AND operation? Or some combination? Better to just call getSecurityManager().checkPermission().
Thanks :-)
How do we make sure both of these are documented in big flashing letters in the development guide? I've been at the python product programming thang for some time (;-) now and I never knew that, in fact I had made completely incorrect assumptions...
cheers,
Chris
Shane
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com """ Killing hundreds of birds with thousands of stones """
From: "Chris McDonough" <chrism@zope.com>
If someone summarizes the distinctions made in this email, I can put it in the ZDG.
1. You can't protect a method with more than one permission. 2. If a method aliases another method: e.g. manage_main = manage_editForm ...then they both HAVE to be protected by the same permission. HTH, Chris
Chris Withers wrote:
From: "Chris McDonough" <chrism@zope.com>
If someone summarizes the distinctions made in this email, I can put it in the ZDG.
1. You can't protect a method with more than one permission.
2. If a method aliases another method:
e.g. manage_main = manage_editForm
...then they both HAVE to be protected by the same permission.
And what about the _setName stuff? How about: When you have two attributes that resolve to the same method, and that method is protected by a permission, you need to call _setName on the method. The argument to _setName is the name of the attribute that you used in the permission declaration. I still don't really understand why this is needed... I guess I'll need to do some digging in the latest security code. -- Steve Alexander Software Engineer Cat-Box limited
On Sat, 28 Jul 2001, Steve Alexander wrote:
Chris Withers wrote:
From: "Chris McDonough" <chrism@zope.com>
If someone summarizes the distinctions made in this email, I can put it in the ZDG.
1. You can't protect a method with more than one permission.
2. If a method aliases another method:
e.g. manage_main = manage_editForm
...then they both HAVE to be protected by the same permission.
And what about the _setName stuff?
How about:
When you have two attributes that resolve to the same method, and that method is protected by a permission, you need to call _setName on the method. The argument to _setName is the name of the attribute that you used in the permission declaration.
I still don't really understand why this is needed... I guess I'll need to do some digging in the latest security code.
Again, this problem has always existed. I was working on a Script (Python) recently and tried to set it up so that a restricted user could edit scripts. Strangely, no security setting (including granting *all* permissions to the user's role) would allow access to the script editing form. I dug further and realized that even though there was a declarePermission() for the edit method, the declaration was being ignored because Zope thought the method was supposed to have a different name. Zope had guessed the name of the method incorrectly. It had assigned security to it in such a way that only users with the "Manager" role, regardless of permissions, could see it. The bug is not easily reproduced because it actually depends on the order of items retrieved from a dict, which is indeterminate. But I assure you, it exists and has probably bitten a lot of us at some time or another. In fact, when I first installed the warning a dozen modules of Zope itself reported the warning. Hopefully a future version of Python will let us solve this in a more elegant way. There would need to be some way to distinguish aliases from original names of DTMLMethods. The "def" statement, for example, automatically includes the canonical name of a function in the produced function object, so there's no ambiguity. Maybe something like: def <DTMLMethod> manage_editForm('editForm', globals()) ... or ... def as DTMLMethod manage_editForm('editForm', globals()) ... or just ... DTMLMethod manage_editForm('editForm', globals()) ... using the conjunction of two identifiers as a signal to call the first identifier with the second identifier as the first argument and anything in parentheses as the remaining arguments, then storing the results of the call in the current scope using the second identifier. Yuk, yuk, yuk :-) You could then do this: Integer a(1) Then you could have a modified syntax that lets you use the equal sign instead of parentheses. Integer a = 1 This-is-why-I'm-not-a-language-designer-ly y'rs, Shane
participants (4)
-
Chris McDonough -
Chris Withers -
Shane Hathaway -
Steve Alexander