> Looks as if your catalog were very old and still has entries
> with request relative resolution.
> With this information, you can try to analyse the problem
> in an interactive Python interpreter.
To have either object or brain's path in output ("tagencies" list).
The most interesting is that accessing via name I've got objects and
[Dieter] this means that some paths could not be resolved (you
get them as paths and cannot get objects).
They probably form the "old" content still using
request relative access.
but accessing via IP I've got ONLY object - no paths...
In this case, all paths can be resolved into objects.
You should select one or two failing paths and
analyse them (this is done best in an interactive
interpreter; under *nix, such an interpreter can be
started with "bin/zopectl debug").
Then I checked the paths I got for presence of objects on them.
Objects are there, so I decided to use
[Dieter] Try "unrestrictedTraverse" (will not work in untrusted code
-- use the interactive interpreter).
If "unrestrictedTraverse" can resolve the path,
this means that the problem is a permission problem:
the user is not allowed to access some object of "path".
The catalog tries two ways to resolve a path:
the modern one uses "physical path" related traversal,
the old one uses request relative Url traversal.
Due to a bug introduced in a recent Zope version
(and I think fixed again in Zope 2.7.6), the modern
approach performs too strict access controls.
This may mean that the request relative Url traversal
is used as a fallback.
The request relative Url traversal is known to
have severe problems with virtual hosting
(also it is not yet known why host specification
via name or IP should make a difference).
I (at your place) would debug "brain.getObject()"
for one of the failing brains.
Please search the mailing list archives for some notes
about debugging Plone/Zope.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -