Package: experimental.publishtraverse
Be stricter about what gets published by Zope.
Publishing here means: when a browser visits a url, you get a response back.See discussions on adexterity pull requestand aCMFPlone issue.FeaturesThis hooks into the default publish traverser of Zope.
It should work for repoze too, but that is not tested.
It works the same as the default publisher, but it is stricter in what it publishes.The big difference is: an object will only be published if it has security assertions.In other words: there must be a permission check.
If anyone can access the object without even checking if they have theViewpermission, then we refuse to show it.Why use this?Several security hotfixes for Plone have been released the past few years that have explicitly made objects unpublishable.
As anonymous user you could visit a url and get some information that you should not be able to see, and the hotfix fixed that.This experimental package doesnotautomatically fix all such issues.
But it provides a fix foroneclass of such issues: objects that are accessible for anyone without a security check.It doesnotfix publishing objects that have a proper permission check but that should not be available for a browser after all.
Several methods have proper permission checks so that only authorized users can use those functions from restricted code, like Python skin scripts or templates.
But when they also have adocstring, Zope by default allows them to be published, and not everyone realizes this.
This experimental package does not do anything about that: it has no way of knowing if publishing a properly protected method was intentional or not.Note that there are other ways to make objects publishable: browser views and namespace publishing are both explicit and good ways of making an object publishable, and they are not affected by this package.Does it work?Try adding/ZopeTimeat the end of the url of your Plone Site.
It should fail to load.DetailsGetting an object for publishing is done by the ZopeBaseRequestclass in itstraversemethod.
It has this code:adapter = queryMultiAdapter((object, self),
                            IBrowserPublisher)
if adapter is None:
    # Zope2 doesn't set up its own adapters in a lot
    # of cases so we will just use a default adapter.
    adapter = DefaultPublishTraverse(object, self)So what we do is: register an adapter that gets picked up in this code.
The basis is this zcml registration:<adapter
    factory=".traverser.StrictPublishTraverse"
    for="* zope.publisher.interfaces.browser.IBrowserRequest"
    />This points totraverser.pywhere we have aStrictPublishTraverseclass that inherits from one of these two classes:try:
    from repoze.zope2.publishtraverse import DefaultPublishTraverse
except ImportError:
    from ZPublisher.BaseRequest import DefaultPublishTraverseDue to inheritance, theStrictPublishTraverseclass implementszope.publisher.interfaces.browser.IBrowserPublisher, which is what we were after.The class lets the original class do its work, returning an object and a path.
But then it does extra checks on the object:Is its name in the list ofKNOWN_NAMES?
Then we publish it.
Currently this is onlyindex_html, which is a name that is used a lot, even when you don’t see it in the url.Is the object a method or function?
Then we check if there are security assertions on it.
So: do you need a role or permission to access this?
If a role or permission is needed and the visitor does not have it, then this point will never be reached: an unauthorized error will already have been raised.
If no role or permission is needed, then we do the change that is the only reason for the existence of this package: we refuse to publish this item.
This will show as a ‘404 Not Found’ error.If you want to dive deeper into what happens internally when Zope publishes an object, see Martin Aspeli’s excellent article onZope Secrets.OptionsThe package looks for these environment variables:EXPERIMENTAL_PUBLISH_TRAVERSE_ONLY_WARNWhen this is set, instead of refusing to publish an object, a warning is logged.
Default: false.EXPERIMENTAL_PUBLISH_TRAVERSE_ACCEPT_KNOWN_NAMESWhen this is set, the list of known names is taken into account:
when an object with a name in the known names is published, we accept it without further checks.
Default: true.EXPERIMENTAL_PUBLISH_TRAVERSE_ACCEPT_IF_ONLY_FOR_ADMINSWhen this is set, if the publishable object is not protected but its container isonlyaccessible for admins, we accept it anyway.
This can happen if its class hassecurity.declareObjectProtected(ManagePortal),
like happens when you use the permissions form of a workflow state in the ZMI.
An admin in this case is someone with role Manager or Site Administrator.
Default: true.Accepted True values are:true,t,1,yes,y.The defaults are intended to be reasonable for the latest official Plone versions, but the defaults may change.InstallationInstall experimental.publishtraverse by adding it to your buildout:[buildout]
...
eggs =
    experimental.publishtraverseand then runningbin/buildoutNo zcml is needed.CompatibilityFine on Plone 4.3, 5.0, 5.1.ContributeIssue Tracker:https://github.com/plone/experimental.publishtraverse/issuesSource Code:https://github.com/plone/experimental.publishtraverseLicenseThe project is licensed under the GPLv2.ContributorsMaurits van Rees,maurits@vanrees.orgChangelog1.1 (2016-11-17)New features:Publish objects when their containers are only accessible for admins.
You do that withsecurity.declareObjectProtected(ManagePortal).
This fixes setting permissions for a workflow state.
You can turn this off by setting the new optionEXPERIMENTAL_PUBLISH_TRAVERSE_ACCEPT_IF_ONLY_FOR_ADMINSto false.
[maurits]Bug fixes:Addedtestextra and improved code quality of package,
with help of plone.app.codeanalysis.
[maurits]1.0 (2016-09-28)Initial release.
[maurits]