Jim Fulton wrote at 2004-1-15 17:23 -0500:
BTW, telling me that an algorithm has changed doesn't constitute a use case. :) I know that algorithm has changed. I assert that we don't need the feature that the change broke. I am open to evidence to the contrary.
Do you have a convincing reason to change the behaviour?
I argue here with consistency:
When the "setDefaultAccess" function is called, it should always be called with sensible (and consistent) arguments.
In my view, it is not consistent, that the function is called with the attribute name when the attribute is accessed via "attribute access syntax" but called with "None" when the same attribute it accessed via "item access syntax".
Huh? Nobody's calling setDefaultAccess with None. Stuart is calling it with a handler function. AFAICT, the use of a handler fucntion is undocumented. It should be documented, but with different semantics than Stuart expects. :)
For security checks, the accessed object should be the driving factor and not the particular way the access is made.
Well, sorry, that's not what this is about. We are talking about what to do when accessing objects without roles. The ability to take the name into account is a feature that only makes sense for named, ie attribute access, imo.
When we do not get this consistent, we open new hidden security holes (as one must always think: can this same object be accessed also in a different way and how have I to secure this way).
Certainly, you have to think about how you provide access to data. Lots of data we provide access to has no security assertions of it's own. Think of accessor methods that return data. If data needs to be protected, you need to think about the access methods you provide.
In the future, item access will work like this:
You will be able to protect __setitem__ operations. Once
someone can use setitem, they can access any key. The value
stored with that key may have pretections of it's own, or not.
That's a matter of application design.However, for backward compataibility, we'll leave things the way they were, at least until Zope 2.9.
Jim
-- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
