Brian Lloyd wrote:
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?
So you have something like: 'Access at all' (this is 'Access Contents Information') 'Access through URL' (the 'expose' flag I talked about in previous posts) 'Access through FTP' 'Access through XML-RPC' etc. This would be for individual Zope objects. For objects that expose methods, perhaps you'd need yet another permission, something like: 'Access methods at all' 'Access methods through URL' .. Of course this sounds like it could get unwieldy, unless there was some clear user interface.
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.
Right.
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.
Um, is there a good workaround then, if you turn it off? I mean, if you turn off 'Access Contents Information' *and* you want a DTML method that generates an index of all subfolders, what do you do? Work with proxies? Regards, Martijn