[Zope3-checkins] SVN: Zope3/trunk/src/zope/app/dublincore/timeannotators.py Unwrap DCadapter in time annotators.

[Albertas Agejevas]

On Fri, Feb 25, 2005 at 08:10:54PM -0600, Garrett Smith wrote:
> > On Fri, Feb 25, 2005 at 04:58:24PM -0600, Garrett Smith wrote:
> >> - The annotator should either explicitly check before setting a DC
> >> attr, or handle the Unauthorized with a no-op (IMO the later is
> >> preferable). 
> >> 
> >> - You (IOW your app) should make sure any principal/role with the
> >> zope.ManageContent permission also has zope.app.dublincore.change.
> > 
> > I disagee with you on both counts.  Imagine a forum where anonymous
> > users post comments.  Your suggestions imply that either DC write
> > access will be public, or modification times will not be updated.
> > This is bogus.
> 
> "anonymous users post comments" -> they have permission to create
> comments and modify some parent. You let them do this, but not modify DC
> on the objects they create? Strange.

So, you imply, all users have to have write access to the DC metadata
on all anonymously added comments?  *That* is strange.

> > A more plausible model would be if the event subscribers could be
> > declared as "trusted" if they do system-level things, like updating
> > the DC metadata or indexes.
> 
> You'd have to setup permission for the handler then. Why not just grant
> the role permission to modify DC?

That's why I used the word "trusted".  For esample, in Unix, you can
change your password, even though you don't have write access to the
/etc/shadow file.  You use a suid root (i.e., trusted) program
/usr/bin/passwd that lets you overcome this security barrier in a
limited well controlled way.

That's why removeSecurityProxy was called trustedRemoveSecurityProxy once.

> > removeSecurityProxy, in essence, does the same thing.  I know it's a
> > hack, but I have failed to find a cleaner solution, and I'm waiting
> > for Jim to tell me what to do :-)
> 
> It's an unacceptable hack, and totally unnecessary. People have gone to
> a lot of effort to get rid of misused removeSecurityProxy.

Well, this one will not going to get forgotten and cause trouble for
people getting rid of misued removeSecurityProxies.  You might have
noticed in my commit message there's a bug in the collector
(http://www.zope.org/Collectors/Zope3-dev/373).  Also, there are
prominent comments in the code pointing to the bug.

Unfortunately, Jim was not around on IRC when I hit this problem, and
Stephan suggested that I do the hack, file a bug, move along with
my work, and point Jim to it later.

> A much better hack would be to register your own event handler, in your
> app, to remove proxy and keep the core free of that.

I don't care for DC!  Zope 3 calls the handler, because the object is
attribute annotatable.  I need it to be annotatable, and I also want
my app to work on an untweaked Zope 3 instance.

Albertas