Dieter Maurer wrote:
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 Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 Zope Corporation

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to