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