Re: [Zope-dev] Zope logic
Adrian Hungate wrote: Bottom line, internal bugs to one side, Z2.x works a particular way, and is documented as doing so. This is a powerful and useful feature, and we are likely to severly impact the power and process of Zopeing by removing it. If we are still heading for 10x we should be enhancing those features that set Zope apart from the competition, not removing features that make it different. I think I'll prefer the power in Zope 3 to the confusion in Zope 2... My 2p, 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] Zope logic
From: Shane Hathaway [EMAIL PROTECTED] Well, I'm not so enthusiastic about it. Implicit acquisition in URLs leads to subtle bugs. One thing that just about every Zope site does is acquire images using a simple relative URL, but that makes the images much less cacheable. Not if you do it with dtml-var Image, if I remember correctly. But sure, you are correct, it's possible to shoot yourself in the foot with this, and using relative urls is a sure way to do this. But having the possibility of letting an object be aqcuired by a whole bunch of subobjects, and overriding it further down in a tree, is still an amazingly great feature. If this feature can be modified so it's harder to shoot yourself in the foot (by for example forcing you to check an Aqcuirable check box before an object gets aquired or whatever), then fine, I have no problem with that. But aqcuisition still a great feature, and together with ZODB, one of the defining features that make Zope so powerful. The browser can't know they are the same image and will have to fetch the image up to three times. This problem explodes on larger sites unless you educate HTML authors. Well, I kinda thought that one of the points with Zope is that you don't need loads of HTML authors, because it's dead easy (thanks in much to aqcuisition) to have design templates, so that you don't *need* to have people doing html all over the place. :-) ___ 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] Zope logic
On Thu, 30 May 2002, Chris Withers wrote: People will be really confused to see such results: http://www.zope.org/Documentation/ZopeBook/Documentation http://www.zope.org/Images Why would they see such URLs? Normally would not. But if I know such a site is managed by Zope, I can easily find such a URL with dead loops. I don't know how search engines like Google handles this situation, at least it will cause unnecessary traffic to the site once a bad guy just simply publish the URL on their own page. I'm a little bit new to Zope. I don't yet have a lot of my own objects created under Zope. But I think there might be some objects like methods or scripts that is URL-sensitive. It will adds lots of tasks to the script itself to filter off unexpected request URLs to avoid generating errors that may turn into security holes. Is there a way to setup an object to be uninheritable or as private to avoid this logic? Or maybe we should workout a way to do so. If you're interested, take a look at Zope 3. However, in your case, you probably need to worry more about why you're generating URLs like the ones above rather than the fact that it is possible to do so. Hackers everywhere. :) Wei He ___ 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] Zope logic
From: Wei He [EMAIL PROTECTED] An object (say index_html) is inherited by child objects of the site say Document to make http://www.domain.com/Document share the upper level index_html. This sounds good but acutally not I think. It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope. People will be really confused to see such results: http://www.zope.org/Documentation/ZopeBook/Documentation Then don't show them these results. :-) http://www.zope.org/Images Whats confusing about that one? I don't know how search engines like Google handles this situation, Search engines follow links. Unless you display a looping link to them, they won't find it, and hence, it's not a problem. Best Regards Lennart Regebro Torped Strategi och Kommunikation AB ___ 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] Zope logic
Lennart Regebro wrote: From: Wei He [EMAIL PROTECTED] An object (say index_html) is inherited by child objects of the site say Document to make http://www.domain.com/Document share the upper level index_html. This sounds good but acutally not I think. It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope. Well, I'm not so enthusiastic about it. Implicit acquisition in URLs leads to subtle bugs. One thing that just about every Zope site does is acquire images using a simple relative URL, but that makes the images much less cacheable. If www.example.com/docs/tutorial/go.gif, www.example.com/docs/go.gif, and www.example.com/go.gif refer to the same image, HTML authors are likely to just choose any of the three. The browser can't know they are the same image and will have to fetch the image up to three times. This problem explodes on larger sites unless you educate HTML authors. Another problem is illustrated by zope.org's version of ZWiki. I don't know if the problem is still there or whether it's in the main ZWiki product. ZWiki uses relative URLs, and some of the URLs displayed on the pages include a trailing slash and some don't. That leads to effective URLs that include doubled names. That's okay until a spider requests URLs like this: http://dev.zope.org/Wikis/DevSite/Proposals/Proposals/Proposals/FrontPage Looking at the zope.org logs, I once saw GoogleBot generate URLs like this to zope.org of 1000 characters or more. Shane ___ 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] Zope logic
On Thursday 30 May 2002 10:29 am, Lennart Regebro wrote: It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope. Is anyone relying on your site to provide information? How do you test your site to make sure that every possible url (not just the ones you link to) do not give out misinformation. Some specific problems that I have encountered: 1. Content that crosses between virtual hosts. If two different virtual hosts come from the same zope then it is possible to construct a URL so that content from one site appears under the hostname (and https certificate!) of another. 2. A page that uses a mix of context and containment If a page is built up with some content found from its context, and other content from containment, then it is possible to construct a URL so that apparently related information comes from unrelated objects. Imagine a medical imaging database, where it was possible for a page do display the wrong patient name above an image. My conclusions are: a. implicit acquisition is dangerous b. acquisition that searches outside the containment hierarchy is evil. Im not keeping up with Zope 3 development. how does Zope 3 handle acquisition? ___ 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] Zope logic
Toby Dickenson wrote: My conclusions are: a. implicit acquisition is dangerous b. acquisition that searches outside the containment hierarchy is evil. Im not keeping up with Zope 3 development. how does Zope 3 handle acquisition? There is no implicit acquisition in Zope 3. If there ever is, it will only be there as part of a Zope 2 compatibility library. Generally if you want something to be acquired by content that lies below it, you make that something a a View, a Resource, or a Utility, or a Service, or some other such thing. There is also an acquire namespace for paths and URLs. I haven't had cause to use that though. You make a choice as to what you want as Content and what you want as behind-the-scenes plumbing. -- Steve Alexander ___ 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] Zope logic
Hmmm... interesting points... However I almost completely disagree. The only part of URL implicit acquisition that I have a problem with is acquiring from outside the VHost, but if you plan properly, you can even avoid this. I have written several sites that use this feature, and I have found no significant problems with it, and as for it being a problem for caching proxies, many of the objects that get acquired are dynamic, and provide different content based on context, so multiple cache entries is the correct answer. Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk - Original Message - From: Toby Dickenson [EMAIL PROTECTED] To: Lennart Regebro [EMAIL PROTECTED]; Wei He [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 4:07 PM Subject: Re: [Zope-dev] Zope logic On Thursday 30 May 2002 10:29 am, Lennart Regebro wrote: It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope. Is anyone relying on your site to provide information? How do you test your site to make sure that every possible url (not just the ones you link to) do not give out misinformation. Some specific problems that I have encountered: 1. Content that crosses between virtual hosts. If two different virtual hosts come from the same zope then it is possible to construct a URL so that content from one site appears under the hostname (and https certificate!) of another. 2. A page that uses a mix of context and containment If a page is built up with some content found from its context, and other content from containment, then it is possible to construct a URL so that apparently related information comes from unrelated objects. Imagine a medical imaging database, where it was possible for a page do display the wrong patient name above an image. My conclusions are: a. implicit acquisition is dangerous b. acquisition that searches outside the containment hierarchy is evil. Im not keeping up with Zope 3 development. how does Zope 3 handle acquisition? ___ 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 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] Zope logic
The namspace traversal in Zope 2 severely violates the principle of least surprise IMO. Although you can use this to clever ends, it opens up many doors to misuse of a site or even significant security holes. For instance, it used to be possible to access the Control Panel (and shutdown Zope) as a user defined in a subfolder of the root who had the local Manager role, just by forming a URL like: http://somezope/myfolder/Control_Panel/manage_main The point is that this grants way too much power to the end user to muck up the namespaces. It is difficult, if not impossible to design an app in Zope today that accounts for all possible namespace variations gracefully, since there are effectively an infinite number of them for every given object in Zope based on different URLs. Now I won't argue that implicit acquisition isn't useful. It rules in solving (and simplifying) problems in creating highly coordinated objects. But, being an implicit and magical thing, it is better if it is invoked through an explicit gesture rather than simply being there all the time. Having it around all the time also makes it easy to use it when its not the best (or most robust) solution because it also excels in creating namespace chaos that is difficult to predict and account for. This is what Zope3 realizes. -Casey On Thursday 30 May 2002 12:42 pm, Adrian Hungate wrote: Hmmm... interesting points... However I almost completely disagree. The only part of URL implicit acquisition that I have a problem with is acquiring from outside the VHost, but if you plan properly, you can even avoid this. I have written several sites that use this feature, and I have found no significant problems with it, and as for it being a problem for caching proxies, many of the objects that get acquired are dynamic, and provide different content based on context, so multiple cache entries is the correct answer. Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk - Original Message - From: Toby Dickenson [EMAIL PROTECTED] To: Lennart Regebro [EMAIL PROTECTED]; Wei He [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 4:07 PM Subject: Re: [Zope-dev] Zope logic On Thursday 30 May 2002 10:29 am, Lennart Regebro wrote: It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope. Is anyone relying on your site to provide information? How do you test your site to make sure that every possible url (not just the ones you link to) do not give out misinformation. Some specific problems that I have encountered: 1. Content that crosses between virtual hosts. If two different virtual hosts come from the same zope then it is possible to construct a URL so that content from one site appears under the hostname (and https certificate!) of another. 2. A page that uses a mix of context and containment If a page is built up with some content found from its context, and other content from containment, then it is possible to construct a URL so that apparently related information comes from unrelated objects. Imagine a medical imaging database, where it was possible for a page do display the wrong patient name above an image. My conclusions are: a. implicit acquisition is dangerous b. acquisition that searches outside the containment hierarchy is evil. Im not keeping up with Zope 3 development. how does Zope 3 handle acquisition? ___ 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 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 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] Zope logic
Hmm... being able to acquire the Control_Panel (or anything) and it taking on the wrong security context was a bug, and AFAIK it has been corrected. Before I start sounding like I did in a previous thread, I am starting to have some very serious doubts about the direction Z3 development is heading. I have been a strong proponent of Zope, in part because of the very features that people seem to be proudly proclaiming will be removed from, or at best depricated in, Z3... Bottom line, internal bugs to one side, Z2.x works a particular way, and is documented as doing so. This is a powerful and useful feature, and we are likely to severly impact the power and process of Zopeing by removing it. If we are still heading for 10x we should be enhancing those features that set Zope apart from the competition, not removing features that make it different. Just my $0.02 Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk - Original Message - From: Casey Duncan [EMAIL PROTECTED] To: Adrian Hungate [EMAIL PROTECTED]; Toby Dickenson [EMAIL PROTECTED]; Lennart Regebro [EMAIL PROTECTED]; Wei He [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 6:43 PM Subject: Re: [Zope-dev] Zope logic The namspace traversal in Zope 2 severely violates the principle of least surprise IMO. Although you can use this to clever ends, it opens up many doors to misuse of a site or even significant security holes. For instance, it used to be possible to access the Control Panel (and shutdown Zope) as a user defined in a subfolder of the root who had the local Manager role, just by forming a URL like: http://somezope/myfolder/Control_Panel/manage_main The point is that this grants way too much power to the end user to muck up the namespaces. It is difficult, if not impossible to design an app in Zope today that accounts for all possible namespace variations gracefully, since there are effectively an infinite number of them for every given object in Zope based on different URLs. Now I won't argue that implicit acquisition isn't useful. It rules in solving (and simplifying) problems in creating highly coordinated objects. But, being an implicit and magical thing, it is better if it is invoked through an explicit gesture rather than simply being there all the time. Having it around all the time also makes it easy to use it when its not the best (or most robust) solution because it also excels in creating namespace chaos that is difficult to predict and account for. This is what Zope3 realizes. -Casey On Thursday 30 May 2002 12:42 pm, Adrian Hungate wrote: Hmmm... interesting points... However I almost completely disagree. The only part of URL implicit acquisition that I have a problem with is acquiring from outside the VHost, but if you plan properly, you can even avoid this. I have written several sites that use this feature, and I have found no significant problems with it, and as for it being a problem for caching proxies, many of the objects that get acquired are dynamic, and provide different content based on context, so multiple cache entries is the correct answer. Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk - Original Message - From: Toby Dickenson [EMAIL PROTECTED] To: Lennart Regebro [EMAIL PROTECTED]; Wei He [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 4:07 PM Subject: Re: [Zope-dev] Zope logic On Thursday 30 May 2002 10:29 am, Lennart Regebro wrote: It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope. Is anyone relying on your site to provide information? How do you test your site to make sure that every possible url (not just the ones you link to) do not give out misinformation. Some specific problems that I have encountered: 1. Content that crosses between virtual hosts. If two different virtual hosts come from the same zope then it is possible to construct a URL so that content from one site appears under the hostname (and https certificate!) of another. 2. A page that uses a mix of context and containment If a page is built up with some content found from its context, and other content from containment, then it is possible to construct a URL so that apparently related information comes from unrelated objects. Imagine a medical imaging database, where it was possible for a page do display the wrong patient name above an image. My conclusions are: a. implicit acquisition is dangerous b. acquisition that searches outside the containment hierarchy is evil. Im not keeping up with Zope 3 development. how does Zope 3 handle acquisition? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http
[Zope-dev] Zope logic
Hi all, I have tried Zope for a week and found a logic problem. An object (say index_html) is inherited by child objects of the site say Document to make http://www.domain.com/Document share the upper level index_html. This sounds good but acutally not I think. People will be really confused to see such results: http://www.zope.org/Documentation/ZopeBook/Documentation http://www.zope.org/Images Is there a way to setup an object to be uninheritable or as private to avoid this logic? Or maybe we should workout a way to do so. Wei He ___ 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] Zope logic
Hi, Wei He wrote: An object (say index_html) is inherited by child objects of the site say Document to make http://www.domain.com/Document share the upper level index_html. This sounds good but acutally not I think. So do a lot of other people, but not for your reasons ;-) People will be really confused to see such results: http://www.zope.org/Documentation/ZopeBook/Documentation http://www.zope.org/Images Why would they see such URLs? Is there a way to setup an object to be uninheritable or as private to avoid this logic? Or maybe we should workout a way to do so. If you're interested, take a look at Zope 3. However, in your case, you probably need to worry more about why you're generating URLs like the ones above rather than the fact that it is possible to do so. 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 )
