Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] RE: objectIds accessiblilty and a proposal
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[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
Dieter Maurer wrote: There are objects, that should be usable by Anonymous inside DTML but should not be viewable over the web (as they will only confuse). All page components (such as "standard_html_header/footer") fall into this category. Totally agree... this has bugged em right since I started usign Zope! :-S cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] RE: objectIds accessiblilty and a proposal
-Original Message- From: Dieter Maurer [mailto:[EMAIL PROTECTED]] Toby Dickenson writes: ... protocol specific access rights ... 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) I agree with you mostly. But it might be a significant difference, whether you access via HTTP or HTTPS or even a protocol that provides trusted authentication. As a matter of principal, authentication issues do not belong in the permissions machinery, but rather in the User machinery. As a matter of practicality, changing the user machinery is also the smallest change that achieves what you want. What if it was possible to specify per-user the level of security required (Basic is ok for some users, another needs https, etc). You could do this today with a custom user folder, but it might make sense to add it to the standard one. Your very-private-method could then be protected by a permission that is only given to users who are configured to require https. This obviously works for normal users, but it applies to anonymous users too The word 'zen' hasnt been used on the list for a while, so ill drop it in here Zope has a standard "Anonymous" user who represents users who do not authenticate. This user has no management interface, and he has a fixed set of roles - this makes him very limited. However, you *dont* *need* *to* *use* *it*. Create your own substitute as a new user (I like to call him "Anon") in the root folder with a blank password. This is useful if you create a product with a feature that you want to make available anonymously today, but may want to authenticate in the future. You could tweak the permissions mapping so that the appropriate permissions are given to the "Anonymous" role, however that leads to alot of re-tweaking when you make the change. A better solution is to create a new role, and grant that role to "Anon". This step (granting special roles to the anonymous user) is the thing you cant do with the regular anonymous user. I hope this helps, ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
On Mon, 18 Dec 2000 14:11:51 -0500, "Brian Lloyd" [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
Toby Dickenson writes: ... protocol specific access rights ... 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) I agree with you mostly. But it might be a significant difference, whether you access via HTTP or HTTPS or even a protocol that provides trusted authentication. Furthermore, I would not bring DTML and web access on the same level: There are objects, that should be usable by Anonymous inside DTML but should not be viewable over the web (as they will only confuse). All page components (such as "standard_html_header/footer") fall into this category. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: objectIds accessiblilty and a proposal
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[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
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 8080no return 404 ftp yes Another example: access route accessible?action called from template yes http on port 8080no 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
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[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com -- Paul Erickson | [EMAIL PROTECTED] Kaivo, Inc. | www.kaivo.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
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. | [EMAIL PROTECTED] `-- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: objectIds accessiblilty and a proposal
[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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
Dieter Maurer wrote: Steve Alexander writes: 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 8080no return 404 ftp yes Another example: access route accessible?action called from template yes http on port 8080no redirect to URL Sounds good to me. With the exception that I do not like the explicit port references. I would like to see there an indirection (e.g. use a name which can be mapped to a port at a central place). I agree, that's a good idea. The accessible state, and the action for a particular access-route could be acquired, like the current security settings. So, I'd have to say in only a single folder's accessing tab that all objects below that folder that are invisible to web traversal should return a 404. Isn't there already a fishbowl proposal for this kind of thing? Did it get anywhere? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
