objectIds -- accesible for everyone -- why?
If you type in http://www.zope.org/Members/objectIds you get a list of all Members. Although it is a useful feature.. ;) .. I can't really see why objectIds should be available for everyone, at any given time. Is this a bug or a feature? -Morten
morten@esol.no wrote:
If you type in http://www.zope.org/Members/objectIds you get a list of all Members. Although it is a useful feature.. ;) .. I can't really see why objectIds should be available for everyone, at any given time.
Is this a bug or a feature?
-Morten
I was able to do this as anonymous on another Zope site as well. It basically lets you do a directory listing of any folderish object. Using objectValues, you can learn the type of objects that live there too. This lets you learn about all objects, even if you do not have view rights to the object listed. However, you do need view rights to the folder you are calling objectIds for. This does seem to me like a way for clandestine users to learn more information about your site than they need to know. Perhaps this "feature" needs to be locked down. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
If you type in http://www.zope.org/Members/objectIds you get a list of all Members. Although it is a useful feature.. ;) .. I can't really see why objectIds should be available for everyone, at any given time.
Is this a bug or a feature?
I was able to do this as anonymous on another Zope site as well. It basically lets you do a directory listing of any folderish object. Using objectValues, you can learn the type of objects that live there too.
This lets you learn about all objects, even if you do not have view rights to the object listed. However, you do need view rights to the folder you are calling objectIds for.
This does seem to me like a way for clandestine users to learn more information about your site than they need to know. Perhaps this "feature" needs to be locked down.
This is something that has come up before. I propose that the real problem here is that 'objectIds' should not be web-traversable. I have, in fact, proposed this before. It caused a bit of grumbling among people using xml-rpc, who were using objectIds remotely, so we never came to closure on it. This comes up often enough that I'm inclined to do something about it for 2.3. I propose that objectIds (and objectValues) will not be directly accessible via the Web in 2.3. For xml-rpc applications, it should be a simple enough task to create a Python Script (or even a DTML Method) that *is* Web accessible to relay that information if it is needed. Thoughts? Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
This comes up often enough that I'm inclined to do something about it for 2.3. I propose that objectIds (and objectValues) will not be directly accessible via the Web in 2.3. For xml-rpc applications, it should be a simple enough task to create a Python Script (or even a DTML Method) that *is* Web accessible to relay that information if it is needed.
Thoughts?
I have no objections to that. On a related issue, what about other dtml snippets that people generally don't want as web accessible, such as standard_html_header ? On my pie-in-the-sky zope wishlist: What I'd like is a new tab for zope objects that allows me to say which protocols the object is accessible from, and what to do if not. For example: access route accessible? action called from template yes http on port 8080 no return 404 ftp yes Another example: access route accessible? action called from template yes http on port 8080 no redirect to URL1 If medusa is ever extended to have http and https on different ports, then you could declare different accessible states and actions for the different http ports. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
On a related issue, what about other dtml snippets that people generally don't want as web accessible, such as standard_html_header ?
On my pie-in-the-sky zope wishlist:
<snip wishlist> I did have a proposal for just this on dev.zope.org, but I see someone has deleted it :-( cheers, Chris
<snip wishlist>
I did have a proposal for just this on dev.zope.org, but I see someone has deleted it :-(
cheers,
Chris
Are you talking about 'ProtocolAccessibility'? It's still there (though Jim has done some rearranging of things there lately)... Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
Are you talking about 'ProtocolAccessibility'? It's still there (though Jim has done some rearranging of things there lately)...
http://www.zope.org//Wikis/DevSite/Proposals/ProtocolAccessibility So it is :-) Comments are still welcome... Chris
On 18 Dec 2000, at 14:11, Brian Lloyd wrote:
This comes up often enough that I'm inclined to do something about it for 2.3. I propose that objectIds (and objectValues) will not be directly accessible via the Web in 2.3. For xml-rpc applications, it should be a simple enough task to create a Python Script (or even a DTML Method) that *is* Web accessible to relay that information if it is needed.
Thoughts?
I think your proposal is the way to go. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
If it is an issue for XML-RPC users, maybe there should be a "Traversable" permission on Folder objects that could default to not allowing web-traversal, but allowing it to be enabled if desired. Would this affect FTP access to folders? -Paul Brian Lloyd wrote:
This is something that has come up before. I propose that the real problem here is that 'objectIds' should not be web-traversable.
I have, in fact, proposed this before. It caused a bit of grumbling among people using xml-rpc, who were using objectIds remotely, so we never came to closure on it.
This comes up often enough that I'm inclined to do something about it for 2.3. I propose that objectIds (and objectValues) will not be directly accessible via the Web in 2.3. For xml-rpc applications, it should be a simple enough task to create a Python Script (or even a DTML Method) that *is* Web accessible to relay that information if it is needed.
Thoughts?
Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
-- Paul Erickson | erickson@kaivo.com Kaivo, Inc. | www.kaivo.com
Paul Erickson wrote:
If it is an issue for XML-RPC users, maybe there should be a "Traversable" permission on Folder objects that could default to not allowing web-traversal, but allowing it to be enabled if desired.
Would this affect FTP access to folders?
-Paul
I agree. That would temper any grumbling and solve the problem (although not the problem of the ever growing security list). -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
[Brian Lloyd] | This comes up often enough that I'm inclined to do | something about it for 2.3. I propose that objectIds | (and objectValues) will not be directly accessible | via the Web in 2.3. For xml-rpc applications, it should | be a simple enough task to create a Python Script (or | even a DTML Method) that *is* Web accessible to relay | that information if it is needed. | | Thoughts? This sounds like a good idea. -Morten
On Mon, 18 Dec 2000 14:11:51 -0500, "Brian Lloyd" <brian@digicool.com> wrote:
This is something that has come up before. I propose that the real problem here is that 'objectIds' should not be web-traversable.
I have, in fact, proposed this before. It caused a bit of grumbling among people using xml-rpc, who were using objectIds remotely, so we never came to closure on it.
Please No. Zope security is complex enough without having to worry about different security settings depending on how a method is accessed. (And we should have a lower tolerance for complexity when it applies to security) If a user has permission to access a method then he should be able to access it any way (xmlrpc, ZPublisher, DTML, PythonMethods) Conversely, if a user is given an "Access Denied" message using one means of access (say, using ZPublisher) then he *must* also be denied using every other one. Security testing is much harder without this property. If anyone is seriously worried about this a a problem then can already deny Anonymous users the 'Access contents information' permission, and grant a proxy role to methods that generate indexes. (Indeed, this may make sense as the default configuration) Toby Dickenson tdickenson@geminidataloggers.com
This is something that has come up before. I propose that the real problem here is that 'objectIds' should not be web-traversable.
I have, in fact, proposed this before. It caused a bit of grumbling among people using xml-rpc, who were using objectIds remotely, so we never came to closure on it.
Please No.
Zope security is complex enough without having to worry about different security settings depending on how a method is accessed. (And we should have a lower tolerance for complexity when it applies to security)
As a compromise, all I've done is make 'objectIds' and 'objectValues' non Web traversable. It is simple enough for anyone who actually _wants_ to use them to write a DTML Method like: <dtml-return objectIds> ...and use that instead of calling 'objectIds' directly over HTTP. This should make those concerned about the exposure of names happier without placing much of a burden on those who want them exposed, and does not complicate the security model. FWIW, I agree that adding access method into the security mix would add a great deal of complexity. It may turn out to be necessary in the future, but I'm not yet convinced of that. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
FWIW, I agree that adding access method into the security mix would add a great deal of complexity. It may turn out to be necessary in the future, but I'm not yet convinced of that.
Well, it's come up quite a few tiems, would it really be that bad? :-S cheers, Chris
morten@esol.no wrote:
If you type in http://www.zope.org/Members/objectIds you get a list of all Members. Although it is a useful feature.. ;) .. I can't really see why objectIds should be available for everyone, at any given time.
Hmm, if these objects are listed in their order of creation, and I'm the 39th object listed (other than index_html), that makes me the 39th user to sign up for a login! Low user ID #s are cool. - Michael Bernstein (webmaven).
On Mon, Dec 18, 2000 at 09:01:28PM -0800, Michael Bernstein wrote:
morten@esol.no wrote:
If you type in http://www.zope.org/Members/objectIds you get a list of all Members. Although it is a useful feature.. ;) .. I can't really see why objectIds should be available for everyone, at any given time.
Hmm, if these objects are listed in their order of creation, and I'm the 39th object listed (other than index_html), that makes me the 39th user to sign up for a login!
Low user ID #s are cool.
- Michael Bernstein (webmaven).
Yeah, I'll mine to my signature... :P -- Martijn Pieters (#6 @ zope.org) | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
participants (10)
-
Brad Clements -
Brian Lloyd -
Casey Duncan -
Chris Withers -
Martijn Pieters -
Michael Bernstein -
morten＠esol.no -
Paul Erickson -
Steve Alexander -
Toby Dickenson