Paul Winkler wrote:
On Mon, May 19, 2003 at 12:34:44PM -0400, Shane Hathaway wrote:
The same thing changed for integers and strings (and probably all other built-in types). The __doc__ check has always been hackish anyway. Ideas?
start declaring security on stuff that's traditionally relied on having no docstring?
We can't, unless we overhaul the security policy. Declarations for built-in types get ignored. This is because the security policy depends on being able to find a __roles__ attribute on the thing accessed. Instances of built-in types do not allow extra attributes (nor should they.) So, for example, declarePrivate('some_string_attribute') has no effect, nor did it ever have any effect. It's a nasty situation. :-( But overhauling the security policy is probably too big a change for making Zope 2.6 compatible with Python 2.2. Ironically, the new docstrings are wrong. ().__doc__ gives you information about how to construct a tuple instead of telling you how to use the tuple you've already created. So we could lobby PythonLabs to fix the docstrings, but that wouldn't solve Zope's problem.
alternatively (I really really hate to suggest this) we could add some checks to BaseRequest.traverse() such that built-in types are not publishable. I hate to suggest it because:
1) traverse is already 266 lines long!
Even so, we might have to do something like this. As another option, I wonder how well it would work to refuse to publish anything that has no __roles__ attribute... or some variation on that.
2) it could sometimes be really handy to have trivial publishable attributes that are built-in types, either for inspecting the state of an object via a browser or for RAD development of an app in the REST style (Representational State Transfer - see http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html for an intro). I could imagine implementing something like:
Zope 2.6 + Python 2.1 tries to disallow access to simple attributes because of the number of things it would let you access that you couldn't before. Yes, it would be useful, but we need Zope 2.6 + Python 2.2 to act the same as Zope 2.6 + Python 2.1.
Admittedly this is a pretty small difference, and a silly example, but there's something really appealing about the simplicity of the first example.
You're going to enjoy Zope 3. ;-) Shane