Z Object Publishing Environment

Search | Download | Documentation | Resources | Members




Join Zope.org
Log in

Developer Home
Get Involved!
The Fishbowl

 Zope Exits

Zope Newbies

page served by app2

Proposals Table of Contents Last edited on Jan 20, 2001 6:00 pm

ProtocolAccessibility Proposal

Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the ProtocolAccessiblityDiscussion to make comments.




You cannot consistently control the accessibility and visibility of objects and methods to the various protocols. This results in a lot of "messiness" and even potential security holes on most sites.

Example Messiness


This looks horrible and I can't imagine many corporates who would be happy to have the "components" of their site on display like this.

Example Potential Security Hole



(http://www.zope.org/objectItems in confusingly not URL accessible ;-)

The sort of information exposed by the above not only shows people objects you may not want them to know about, it provides the sort of information that crackers like to play with and exploit.

There are currently several ways to prevent access from certain protocols, but only from python. For example, you can start your method/object name with _, which makes it invisible just about everywhere except python code. Alternatively, you can leave out the method's python DocString which means it'll only be accessible through DTML, but not directly via a URL. Finally, protocols like FTP and DAV seem to be limited by lack of handler implementation rather than conscious decision.

These are all very unorganised and throwbacks to former times (Principia and Medusa, IIUC ;-) and, AFAIK, there's no equivalent for use in the DTML/ZClasses realm.

Proposed Solution

In essence, add a new management tab called Protocol Accessibility. This would consist of a checkbox for each protocol. If the box is checked, the object/method is accessible through that protocol. If the box is unchecked, not only is that object/method not accessible through the protocol, if it is requested a Not Found rather than an Unauthorized will be returned.

A similar interface will need to be provided in python, in the same way __ac_permissions__ mirrors the functionality of the Security Tab.

It may be useful to change the Security tab to use MultiRowManageTabs in the process.


An overhead will be introduced to check whether or not each object/method is accessible.

Unless done carefully, new users may be exposed to stuff they shouldn't have to care about until they want to.


The scope is to cover the protocols that are currently in use. Hopefully, whatever is implemented would cover future protocols but that isn't specifically within the scope.


  • changes to the Security tabe or a new Protocol Accessibility Tab

  • an appropriate python interface

  • documentation in the API docs and a guide on use.

View source ProtocolAccessibility
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search:
Privacy policy       Printable Page       Feedback about Zope.org