FrontPage ProtocolAccessibility / backlinks

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.

Contact

ChrisW

Problem

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

http://www.zope.org/standard_html_footer

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/objectIds

http://www.zope.org/objectValues

(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.

Risks

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.

Scope

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.

Deliverables

• 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.