[Zope-dev] Methods through the Web (security?)

Brian Lloyd Brian@digicool.com
Wed, 17 May 2000 17:23:25 -0400


> 
> Hmm, another ZAZ fan :-)
> 

Don't get me started... :^)

> > a holdover from the bobo days - if you are a method and you have a
> > docstring, you are accessible through the web (but still subject to 
> > the std security rules). objectIds and objectValues are a good 
> > example of things that really only want to be used from DTML and 
> > thus shouldn't have docstrings. I've changed this (and a few other
> > iffy methods) for the next release.
> 
> Won't this break Amos' XML-RPC-based editor and similar hacks?

Waaa.... probably. Ok, so I've _provisionally_ changed this in 
the current CVS. I feel a to-the-death-cage-match coming on.

> Can't you just turn off 'Access contents information' permission or
> whatever it is on a folder if you don't want people to call
> those things trough the web?

Yes you could, except that you would also make them inaccessible
from DTML (or from anywhere else) for the same class of users. 

Is it really acceptable that in order to use <dtml-in objectIds>
on a page that needs to be accessible to anonymous users that I 
must grant 'Access contents information' to anonymous users and
thus give them the ability to inspect my objects if they want to? 

I have a feeling that intent will need to become more important
somehow in the future. As we add more protocols and types of 
usage to Zope, it becomes harder for a single permission to 
really cover a resource in a way that makes sense for all of 
the various usages. From the point of view of an xml-rpc based
client app, having objectIds and the like may be an absolute 
necessity, while from a pure HTTP standpoint many would 
at best consider it superfluous or at worst consider it
a security hole.

*sigh*. Maybe the right short-term thing is to just leave it 
the way it was and tell people who may be concerned about it 
to turn it off via that permission and live the repercussions 
that will have in their DTML. I guess at least that way the 
software isn't taking the choice out of their hands.


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com