Zope URL namespaces also looked up as views, unexpectedly mask other names

Zope provides a mechanism to explicitly identify path elements in a URI as belonging to a certain "namespace." The spelling is ++NAMESPACE++PATH_ELEMENT. As an example, "/foo/" can cause a database object to be looked up with the identifier "foo", while "/++etc++foo/" might cause a completely separate lookup for the name "foo," as registered in the "etc" namespace.

Unfortunately, the registration of namespaces is leaky: they also will be looked up as views, if no view of the same name exists. This is because namespaces are registered for adapting (context, request) and providing zope.traversing.interfaces.ITraversable, and views are looked up for adapting (context, request) and providing anything at all.

This means, for example, that the following, original symptoms of this bug and bug 589011 happens:

"""
Visit https://launchpad.net/

in the search box type 'oops' and search. should take you to https://edge.launchpad.net/+search?field.text=oops

where the first hit under 'exact matches' is
Oops (Proprietary)
This project is about associating log information with an event. Later, when an event becomes interesting (an
...

This project doesn't seem to really exist, LOSA's can't access it even.
"""

The project did exist, and the search results were correct to include it. The problem was that traversal was blocked by this leaky registration.

This is true of any registered URI namespace. This is probably reasonably indicative of the specific problems we have:

$ make harness
>>> from zope import component
>>> from zope.traversing.interfaces import ITraversable
>>> from zope.interface import Interface
>>> gsm = component.getGlobalSiteManager()
>>> from zope.publisher.interfaces.browser import IBrowserRequest
>>> gsm.adapters.lookupAll((Interface, IBrowserRequest), ITraversable)
((u'resource', <class 'zope.traversing.namespace.resource'>), (u'oops', <class 'canonical.launchpad.webapp.errorlog.OopsNamespace'>), (u'form', <class 'canonical.launchpad.webapp.namespace.FormNamespaceView'>), (u'view', <class 'zope.traversing.namespace.view'>))

The proper fix would be to make view registration in the Zope framework actually based on a view being registered for a specific view interface, rather than anything at all. Backwards compatibility concerns make this very unlikely to happen.

Another approach would be to change our navigation to reject views that provide ITraversable. There are at least two reasons why this is a bad idea. First, ITraversable is a generic interface, and views sometimes legitimately provide it. Second, our navigation code is spread out over many modules, so changing this logic would be fragile.

A third approach would be to automatically or manually register null adapters to hide the namespace registrations from view lookup. Here's an example of manual registration that just fixes the "oops" namespace, as a proof of concept:

=== modified file 'lib/canonical/launchpad/webapp/errorlog.py'
--- lib/canonical/launchpad/webapp/errorlog.py 2010-05-15 17:43:59 +0000
+++ lib/canonical/launchpad/webapp/errorlog.py 2010-06-04 15:31:28 +0000
@@ -24,7 +24,7 @@
 from zope.error.interfaces import IErrorReportingUtility
 from zope.event import notify
 from zope.exceptions.exceptionformatter import format_exception
-from zope.interface import implements
+from zope.interface import implements, implementer, Interface
 from zope.publisher.interfaces.xmlrpc import IXMLRPCRequest
 from zope.traversing.namespace import view

@@ -695,3 +695,7 @@
         # Store the oops request in the request annotations.
         self.request.annotations[LAZR_OOPS_USER_REQUESTED_KEY] = True
         return self.context
+
+@implementer(Interface)
+def adapter_mask(*args):
+ return None

=== modified file 'lib/canonical/launchpad/webapp/errorlog.zcml'
--- lib/canonical/launchpad/webapp/errorlog.zcml 2009-07-23 05:02:47 +0000
+++ lib/canonical/launchpad/webapp/errorlog.zcml 2010-06-04 18:19:22 +0000
@@ -35,5 +35,16 @@
         provides="zope.traversing.interfaces.ITraversable" for="*"
         factory="canonical.launchpad.webapp.errorlog.OopsNamespace"
         />
+ <!-- Because Zope view lookup is for factories that provide *any*
+ interface (an underlying problem in the framework that cannot be
+ fixed now without serious backwards compatibility problems), the
+ above will appear as a view and mask database objects in
+ traversal for the "oops" name unless we register a mask, as below.
+ See bug -->
+ <adapter
+ name="oops"
+ for="* zope.publisher.interfaces.IRequest"
+ factory=".errorlog.adapter_mask"
+ />

 </configure>

I'm going to pursue an automatic version of this approach. We could catch an event signaling the start of publishing, which will be after zcml has been processed. We could then automatically register adapter masks for all registered ITraversables that do not have views registered for them.