| 2010-06-03 04:01:23 |
Robert Collins |
bug |
|
|
added bug |
| 2010-06-03 17:47:27 |
Gary Poster |
affects |
launchpad |
launchpad-registry |
|
| 2010-06-03 18:09:40 |
Curtis Hovey |
launchpad-registry: status |
New |
Invalid |
|
| 2010-06-03 18:11:43 |
Curtis Hovey |
summary |
searching for 'oops' on home page gives strange Proprietary project as first result |
Cannot access project with blacklisted name |
|
| 2010-06-03 19:54:09 |
Robert Collins |
launchpad-registry: status |
Invalid |
New |
|
| 2010-06-03 19:54:19 |
Robert Collins |
affects |
launchpad-registry |
launchpad-foundations |
|
| 2010-06-03 19:54:37 |
Robert Collins |
summary |
Cannot access project with blacklisted name |
blacklisted project shows up in search results |
|
| 2010-06-03 20:02:09 |
Gary Poster |
launchpad-foundations: status |
New |
Triaged |
|
| 2010-06-03 20:02:19 |
Gary Poster |
launchpad-foundations: importance |
Undecided |
Low |
|
| 2010-06-03 21:21:09 |
Robert Collins |
summary |
blacklisted project shows up in search results |
non blacklisted webapp hooks subtly break search |
|
| 2010-06-03 21:22:46 |
Robert Collins |
description |
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. |
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.
-------------------
Some data:
- oops isn't blacklisted
- there is a webapp ++oops++ handler
This may be a simple bug, or a systemic issue with webapp handlers.
If its a systemic issue with webapp handlers - that is, if anytime someone adds one we have to blacklist names to make things work, then we should have some code that tells us we need to blacklist the handler, or something like that. |
|
| 2010-06-04 16:01:29 |
Gary Poster |
summary |
non blacklisted webapp hooks subtly break search |
Zope URL namespaces also looked up as views, unexpectedly mask other names |
|
| 2010-06-04 18:29:04 |
Gary Poster |
description |
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.
-------------------
Some data:
- oops isn't blacklisted
- there is a webapp ++oops++ handler
This may be a simple bug, or a systemic issue with webapp handlers.
If its a systemic issue with webapp handlers - that is, if anytime someone adds one we have to blacklist names to make things work, then we should have some code that tells us we need to blacklist the handler, or something like that. |
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. |
|
| 2010-06-04 21:01:47 |
Gary Poster |
launchpad-foundations: assignee |
|
Gary Poster (gary) |
|
| 2010-06-04 21:03:38 |
Gary Poster |
branch linked |
|
lp:~gary/launchpad/bug589010 |
|
| 2010-06-11 07:31:08 |
Ursula Junque |
launchpad-foundations: milestone |
|
10.06 |
|
| 2010-06-11 07:31:09 |
Ursula Junque |
launchpad-foundations: status |
Triaged |
Fix Committed |
|
| 2010-06-11 07:31:12 |
Ursula Junque |
tags |
|
qa-needstesting |
|
| 2010-06-15 13:06:57 |
Curtis Hovey |
tags |
qa-needstesting |
qa-ok |
|
| 2010-07-07 13:56:10 |
Curtis Hovey |
launchpad-foundations: status |
Fix Committed |
Fix Released |
|
