On Wed, Dec 19, 2007 at 08:32:02PM +0100, Lorenzo Gil Sanchez wrote:
> <require
>         permission="zope.ManageContent"
>         interface=".interfaces.IMyContent"
>         />
> <page
>       for="mypackage.interfaces.IMyContent"
>       name="welcome.html"
>       class=".views.IndexView"
>       permission="zope.View"
>       template="index.pt"
>       title="Index" menu="zmi_views"
>       />
> As you can see there is a contradiction here: the view is 'public' but
> the object is 'private'.  I see it now but it tooked my a while to
> discover it. Obviously I have a bunch of content types, packages and
> configure.zcml files so it was not so easy.
> So the real problem in my opinion is how Zope helps us to discover
> this kind of configuration bugs. All I have was an 'Internal Server
> Error' (500) and a stack trace like this:
> --- <exception caught here> ---
>   File "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/twisted/web2/wsgi.py", 
> line 139, in run
>     result = self.application(self.environment, self.startWSGIResponse)
>   File 
> "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/zope/app/wsgi/__init__.py", 
> line 55, in __call__
>     request = publish(request, handle_errors=handle_errors)
>   File 
> "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/zope/publisher/publish.py", 
> line 141, in publish
>     publication.handleException(
>   File 
> "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/zope/app/publication/zopepublication.py",
>  line 261, in handleException
>     self._logErrorWithErrorReportingUtility(object, request, exc_info)
>   File 
> "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/zope/app/publication/zopepublication.py",
>  line 215, in _logErrorWithErrorReportingUtility
>     'error reporting utility')
>   File 
> "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/zope/app/publication/zopepublication.py",
>  line 384, in beginErrorHandlingTransaction
>     self.annotateTransaction(txn, request, ob)
>   File 
> "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/zope/app/publication/http.py", 
> line 55, in annotateTransaction
>     txn = super(BaseHTTPPublication, self).annotateTransaction(
>   File 
> "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/zope/app/publication/zopepublication.py",
>  line 197, in annotateTransaction
>     path = locatable.getPath()
>   File 
> "/home/lgs/Python-2.4.4/Zope-3.3.1/lib/python/zope/location/traversing.py", 
> line 147, in getPath
>     path.append(context.__name__)
> zope.security.interfaces.Unauthorized: (<mypackage.mycontent.MyContent object 
> at 0xa9e3aec>, '__name__', 'zope.ManageContent')
> Some questions arises:
> - Why didn't it pop up the typical http challengue asking me for credentials 
> when
> it discovered that I was trying to access an object and I didn't have the
> appropiate permissions?

It appears to be a bug.  You're not seeing the original exception, but a
second one that happened when Zope was trying to log the original one.
I suppose ZopePublication.annotateTransaction should
removeSecurityProxy() from ob before adapting it to

> - Why do I have to define permissions for a view if I already
> configured the same permissions for the class? The view should always
> have more restrictive permissions that the content type class or is
> there any use case for the opposite?

The view doesn't know the permission of the content class.  Note that
your view is registered on IMyContent, and not on MyContent directly.
You might register more than one content class implementing IMyContent,
and register different permissions.

Another thing -- you might protect different attributes with different
permissions, and the view directive cannot be smart enough to analyse
all your source code and page templates to see which of those content
attributes you want to use in this particular view.

> - Is the above stack trace clear enough for experienced zope3
> developers so they can quickly spot the problem or is it just me that
> I couldn't figure it out for a long time?

I've seen before the sort of tracebacks left by an exception that
happens when Zope is trying to render an exception view.  The <exception
caught here> seems familiar, and "self._logErrorWithErrorReportingUtility"
in the traceback is a big hint.

Marius Gedminas
We don't really understand it, so we'll give it to the programmers.

Attachment: signature.asc
Description: Digital signature

Zope3-users mailing list

Reply via email to