AW: AW: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished)
HI Jim Betreff: Re: AW: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished) [...] Configure views on layers will prevent us form backdoors if we reuse this easy installable eggs ;-) Here is a simple sample of such a built-in backdoor: At our fresh zope installation: http://localhost:8080/@@absolute_url Of corse it's not this dangerous, but it shows you what I mean. How do skins avoid this? Let me explain first how I define layer and skins. - A layer is a configuration discriminator (request type) for traversable components. - A named skin (configuration) makes it possible to traverse components using a context and this layer as disriminator as url path. This means in my point of view a layer is a concept which offers a configuration namespace which somebody can use or not. If a layer has allready defined views it doesn't affect anything till we map this layer as traversable namespace. By a traversable namespace I mean the layer registered by its traversable name. Also called skin and accessible by ++skin++Name. If we register absolute_url in a layer which isn't used in a skin, then this view is not available as traversable view because of the missing layer/named skin configuration. Regards Roger Ineichen Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Monday 17 December 2007, Jim Fulton wrote: WRT this use case, I strongly suspect it would be simpler and easier to support defining multiple configurations in ZCML and a mechanism to specify different configurations for different sites within an instance. In fact, I think Stephan Richter added this a while ago. Yes, see z3c.baseregistry. Base registries effectively allow skinning of all components registered with the component registries. This includes adapters and utilities. I sometimes call base registries a way to do site-based component skinning. :-) However, see my other responses (when written ;-) on why skins are still useful. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Monday 17 December 2007, Jim Fulton wrote: As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality. I don't have this use case. I wonder how many people do. I certainly do have this use case all the time. :-) We often have to write a publically facing and an admin UI. The admin UI should not be available publically. With skins this can be solved very elegantly. In a bigger project, we have a true hosted services environment, where customers want very customized UIs, both in look and feel. In those cases skinning is very important to us, since we can choose which layer we have to use as bases for the custom skin. We tend to think up complex use cases and then make the zope framework more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their solutions should generally not be inflicted on the masses. I think that using default browser layer is the way for people not to worry about skins. However, I have found that this is a really bad long-term solution. The biggest problem is that I do not have any control over the default browser layer. I install a package to use its API, but often get a lot of views for the default browser layer as well. Without careful review, there is now way for me to tell whether this opens a security hole. It is thus much safer, to start a new skin from scratch, and carefully add registrations. We developed some minimal base skins (see z3c.layer), which do the most basic setup and which we reviewed somewhat for security. And even if the the security is okay, I would not want to expose all the views. I want control, but often, registering everything from scratch is very tedious. Layers -- and thus skins -- act as collection s of view registrations. I think that z3c.form* demonstrates this very nicely. If I only use the IFormLayer, I only get the widgets, and only by inheriting from IDivFormLayer or ITableFormLayer, I also get form layout components. As Jim pointed out in another E-mail, base component registries (such as z3c.baseregistry) can solve this problem, but only partially. Base registries can only be applied on the site-level. So sure, I can customize the look and feel (and much more) for every site. But for skinning I often want multiple UIs for the *same* site. This problem cannot be solved with base registries today without writing additional software. And this use case is extremely important to us! Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Mon Dec 17 12:00:00 2007 UTC to Tue Dec 18 12:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Dec 17 20:54:16 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-December/008811.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Dec 17 20:55:46 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-December/008812.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Dec 17 20:57:32 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-December/008813.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Dec 17 20:59:02 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-December/008814.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Dec 17 21:00:32 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-December/008815.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DateTime, Australian and US Timezones
How does other software handle this? pytz, most importantly? I found a bug report in Java about the same thing, and they said use another name, i.e. Australia/Eastern or AEST, which are both unambiguous. And how does Brazilians solve it? They also have an EST. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: AW: AW: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished)
On Dec 18, 2007, at 5:08 AM, Roger Ineichen wrote: HI Jim Betreff: Re: AW: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished) [...] Configure views on layers will prevent us form backdoors if we reuse this easy installable eggs ;-) Here is a simple sample of such a built-in backdoor: At our fresh zope installation: http://localhost:8080/@@absolute_url Of corse it's not this dangerous, but it shows you what I mean. How do skins avoid this? Let me explain first how I define layer and skins. - A layer is a configuration discriminator (request type) for traversable components. - A named skin (configuration) makes it possible to traverse components using a context and this layer as disriminator as url path. This means in my point of view a layer is a concept which offers a configuration namespace which somebody can use or not. If a layer has allready defined views it doesn't affect anything till we map this layer as traversable namespace. By a traversable namespace I mean the layer registered by its traversable name. Also called skin and accessible by ++skin++Name. If we register absolute_url in a layer which isn't used in a skin, then this view is not available as traversable view because of the missing layer/named skin configuration. Which does nothing to protect you from components registered for the default layer or for IBrowserRequest. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: AW: [Zope-dev] Request typing (to get the xmlrpc layer discussionfinished)
On Monday 17 December 2007, Roger Ineichen wrote: Layers and skins are a security concept. And a very good one. Let me briefly explain what Roger refers to by the word security here. We consider, as I mentioned in my previous mail, the availability of views outside of our control a security risk, because someone could have done a mistake or maliciously created a security hole in a view. By controlling the contents of the layers more explicitly, we have a better idea of the views that are available. Furthermore, skins allow us to control the permission settings of our views; overrides allow this as well, of course. Of course, this in itself is not enough to ensure security, but I hope that tools like the one started in z3c.securitytool will eventually help us with analyzing our public views. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: AW: AW: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished)
On Tuesday 18 December 2007, Jim Fulton wrote: If we register absolute_url in a layer which isn't used in a skin, then this view is not available as traversable view because of the missing layer/named skin configuration. Which does nothing to protect you from components registered for the default layer or for IBrowserRequest. Yes, because in our code we never ever expose the registrations in the default layer. We consider that layer hostile. :-) (Eventually we hope to rid ourselves from even importing any configuration that registers into the browser layer, but the Zoep packages need some refactoring to do this in a sane way.) IBrowserRequest is a big problem, since it is the base interface for all layers. I used to scan the ZCML for components registered for IBrowserRequest. I have not done this in a while, but should make it a habit again. I hope that security analysis tools, such as z3c.securitytool will eventually help us identify those problems. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Monday 17 December 2007, Christian Zagrodnick wrote: a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it. Since the original implementation and discussion, I had a lot more time to discuss this proposal with Roger (who was heavily in favor of it), think about it, and work on other HTTP-based protocols. Thus, I am now in favor of a solution. It is good that you laid out the implementation details as well. Let me first summarise: * Skin and layers should be seen as typing the request. Well, that's what they actually do. * There are no general objections against having layers for XML-RPC. I think there were pretty strong objections to layers for XML-RPC and all other non-browser HTTP requests. * There are objections against using ++skin++ for XML-RPC, ++api++ would be fine. I think I was against anything typing non-browser related. Therefore we propose to: * Create in zope.publisher.interfaces: class IRequestType(zope.interface.interfaces.IInterface): pass This is good. * Rename IXMLRPCSkinType to IXMLRPCAPIType(IRequestType) and create a traverser ++api++ for IXMLRPCApiType. This would not fulfill the use case that Fred brought up in his response to the proposal. I really like his points and his historical considerations. I think, it would be ideal to have one way to specify the request type, maybe through ++type++. If, for legacy reasons, ++skin++ is easier to use, then that's fine with me too. Let's widen our considerations to JSON and REST as well. What do others think? * Use IRequestType as new base of IBrowserSkinType (instead of IInterface). Okay. * Do *not* provide any traverser for IRequestType since the traversers should be close to the “channel†so it is easy to understand what is happening. If the traverser name is too far fetched we end in confusion like with skin for xmlrpc. Right, this is very important. The same rule should apply for IBrowserRequest; see the other discussion thread of this mail. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DateTime, Australian and US Timezones
OK, I have looked HARD at this now. And dateutil.tz solves this. I don't think Zope can solve this with pytz, unless we implement the same solution in pytz as already exists in dateutil.tz. It solves it by implementing a tzinfo class that wraps zoneinfo files, and that way you simply wrap /etc/localtime and get the right info. I have tried the suggested solution of matching TZ names and offsets and it doesn't work, becuase you'll end up in the correct time zone but not in the correct location, and hence not with the correct daylight saving. More info: http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-beast/ -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.11] Stepping forward and going beta
Andreas Jung wrote: the Zope 2.11 beta phase has been delayed for while. The reason for holding but the release was Philipps and Hannos work on the http://svn.zope.org/Zope/branches/philikon-aq/ branch. Unfortunately both can't work (lack of personal time) on the branch and finish it in the feature. So I propose to release Zope 2.11 beta 1 by the end of the year w/o this branch. Zope 2.11 would contain the Zope 3.4 and ZODB 3.8 with blob support as major new features. Objections? Thoughts? +1 btw. Is there an ETA for beta1? The only thing I'm going to do if no one objects is to deprecate calling the ViewPageTemplateFile in Five without passing in the view. This should at least allow us to merge the aq-branch without any problems for Zope 2.13 if noone can think of a way around the problem. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope 2.11] Stepping forward and going beta
--On 18. Dezember 2007 21:53:55 +0100 Hanno Schlichting [EMAIL PROTECTED] wrote: Andreas Jung wrote: the Zope 2.11 beta phase has been delayed for while. The reason for holding but the release was Philipps and Hannos work on the http://svn.zope.org/Zope/branches/philikon-aq/ branch. Unfortunately both can't work (lack of personal time) on the branch and finish it in the feature. So I propose to release Zope 2.11 beta 1 by the end of the year w/o this branch. Zope 2.11 would contain the Zope 3.4 and ZODB 3.8 with blob support as major new features. Objections? Thoughts? +1 btw. Is there an ETA for beta1? During x-mas and new year..likely around December 29th. If you need some more days, let me know but I would like to push the beta 1 release asap. The only thing I'm going to do if no one objects is to deprecate calling the ViewPageTemplateFile in Five without passing in the view. This should at least allow us to merge the aq-branch without any problems for Zope 2.13 if noone can think of a way around the problem. 2.13? That's science fiction :-) Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK E-Publishing, Python, Zope Plone development, Consulting pgpTRekg0mcme.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
