Re: [Zope-dev] restrictedTraverse
On Sunday, May 12, 2002, at 01:27 AM, Florent Guillaume wrote: With an object path /A/B/C where C has a local role allowing a user to view C but where B disallows acquisition of the View permission, the publisher correctly allows the user to see C. However restrictedTraverse('/A/B/C') fails (You are not allowed to access B in this context). This is because restrictedTraverse checks the security (using validate) at *every* step, and obviously the user is not allowed to see B. Is there a reason for this ? Why not simply validate only at the last step ? Note that it doesn't check for the View permission though - it checks for the 'Access contents information' permission. If this fails, it fails because the site manager has explicitly said that a group of users is not allowed to access any objects below this point. If restrictedTraverse did not behave live this, a site manager would need to check the permissions on every single object in a subtree if they needed to restrict access to it, as well as every single object created in that subtree in the future. The current behaviour means that someone with 'Manage permissions' cannot make an object world viewable if it is in an area that the site manager has designated as restricted. It means that an object can be created in a restricted area and it stays restricted, even if it defaults to world viewable (such as an object that defines __allow_access_to_unprotected_subobjects__=1, or objects dynamically created from external sources like the file system or an RDBMS). I have the need to programatically access object protected in such a way. The workaround I'm going to use in my code for now is to call unrestrictedTraverse and validate() by hand the resulting object. But I'm concerned that there may be a more profound security reason I'm missing. You may end up exposing an object that was never meant to be exposed to the user, as previously it was relying on permissions set in a parent container? You may be better off by granting the 'Access contents information' on B or allowing it to be aquired. -- Stuart Bishop [EMAIL PROTECTED] http://shangri-la.dropbear.id.au/ ___ 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: stacks != easy to explain
Correct me if I am wrong, but isn't the TTW part is what is one of the strenghts of Zope - Well, no, not really. Being able to edit stuff remotely is where Zope's real strength lies. WebDAV and FTP are much better than using sucky HTTP forms to do this ;-) Babies. bathwater. Just because ChrisW has gone beyond TTW editing, does not make it a Bad Thing(tm) in general :) I challenge you to justify how editing in a text box is better than using a full text editor, given that both can be used remotely ;-) Hmm... now if I can only find an editor that is worth me spending my valuable time trying to make it do what I want, instead of what it wants for my code Or there are those nice little text boxes... they don't assume they know better than me... It seems that ZPT is mostly aimed at the Page Designer, whereas DTML is mostly aimed at the Developer. Would this be a correct assesment of the situation? DTML didn't have a clue who it was aimed at, which was it's main problem ;-) Hmm... strange then that I have used (as have many others) it to produce some very complex (And some think atractive and even elegant) sites. I had always assumed it was aimed at people who wanted to design websites with some server side inteligence - Seems a logical assumption, after all that is what it allows. *grinz* 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] stacks != easy to explain
From: Steve Alexander [EMAIL PROTECTED] Subject: Re: [Zope-dev] stacks != easy to explain If you're using ordered attributes, then you're not using XML. Indeed, and if your indentation is meaningful in your C source-code, you're not using C. However, that doesn't negate the benefit of a consistent coding style. Indentation style and the definition of XML are two different things. The XML spec clearly states that attributes are defined as unordered. So any XML editors or tool might rightfully reorder those attributes, thus mangling the meaning of any so-called XML code that depends on attribute order. Any so-called XML tool that depends on the order of attributes incorrect, and has a fundamental design flaw because it deviates from the agreed-upon standard. Just as any so-called C compiler that depends on indentation style is incorrect. -Don Reference: http://www.w3.org/TR/xml-infoset/ XML Information Set W3C Recommendation 24 October 2001 2. Information Items 2.2. Element Information Items An element information item has the following properties: 5. [attributes] An unordered set of attribute information items, one for each of the attributes (specified or defaulted from the DTD) of this element. Namespace declarations do not appear in this set. If the element has no attributes, this set has no members. ___ 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] stacks != easy to explain
Don Hopkins wrote: Indentation style and the definition of XML are two different things. The XML spec clearly states that attributes are defined as unordered. So any XML editors or tool might rightfully reorder those attributes, thus mangling the meaning of any so-called XML code that depends on attribute order. Any so-called XML tool that depends on the order of attributes incorrect, and has a fundamental design flaw because it deviates from the agreed-upon standard. Just as any so-called C compiler that depends on indentation style is incorrect. ...which is precisely why the order of attributes in ZPT source code doesn't matter and why the order of execution of attributes is rigidly defined by ZPT, rather than being that of their order in the source. Anyone got a spare Dime Bar? Chris Reference: ...no one cares. ___ 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] stacks != easy to explain
I believe what is trying to be explained is that ZPT provides a certain sequence for attribute *processing*, which begins *after* the template is parsed (like unordered keyword arguments in Python). How they are ordered in the source file is irrelevant, but by ordering them in the precise way they will be processed is recommended to aid in the understanding of what will happen. If you do see a concrete example of how and where this occurs that coincides with a breach from the XML spec, please post this to the list for us to see, so that the proper avenues of discussion, hacking, and problem resolution can be made. ZPT is nowhere near complete, and will surely tighten up with time. Regards, Eron On Thu, 2002-05-16 at 10:32, Don Hopkins wrote: From: Steve Alexander [EMAIL PROTECTED] Subject: Re: [Zope-dev] stacks != easy to explain If you're using ordered attributes, then you're not using XML. Indeed, and if your indentation is meaningful in your C source-code, you're not using C. However, that doesn't negate the benefit of a consistent coding style. Indentation style and the definition of XML are two different things. The XML spec clearly states that attributes are defined as unordered. So any XML editors or tool might rightfully reorder those attributes, thus mangling the meaning of any so-called XML code that depends on attribute order. Any so-called XML tool that depends on the order of attributes incorrect, and has a fundamental design flaw because it deviates from the agreed-upon standard. Just as any so-called C compiler that depends on indentation style is incorrect. -Don Reference: http://www.w3.org/TR/xml-infoset/ XML Information Set W3C Recommendation 24 October 2001 2. Information Items 2.2. Element Information Items An element information item has the following properties: 5. [attributes] An unordered set of attribute information items, one for each of the attributes (specified or defaulted from the DTD) of this element. Namespace declarations do not appear in this set. If the element has no attributes, this set has no members. ___ 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 ) --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] ___ 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] stacks != easy to explain
[Lots of Cc: deleted] My turn... So any XML editors or tool might rightfully reorder those attributes, thus mangling the meaning of any so-called XML code that depends on attribute order. The so-called XML code does *not* depend on attribute order. Any so-called XML tool that depends on the order of attributes incorrect, and has a fundamental design flaw because it deviates from the agreed-upon standard. The so-called XML code does *not* depend on attribute order. The so-called XML code evaluates attributes in a prespecified order, whatever the attribute order in the so-called XML code itself. Just as any so-called C compiler that depends on indentation style is incorrect. That's why it's so-called Python. ;^) -- Two witches watch two watches. Which witch watched which watch? Nicola Larosa - [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: References to hypertext templating languages
[Lots of Cc: deleted...] snipHello?! How much stuff... sorry, I didn't even read it/snip You should have, it's interesting stuff, better not dismissing it so lightly. -- Two witches watch two watches. Which witch watched which watch? Nicola Larosa - [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] References to hypertext templating languages
Don, it sounds like HyperTIES Markup Language addresses some similar purposes in similar ways to Zope Page Templates. There are also some significant differences, which may interest you. ZPT has some distinctive features particularly aimed to promote ease of collaboration between web designers and programmers (or between those two sides of a developer, working with themselves.-) Chief among those features is use of tag attributes for computation hookup - variable access, conditionals, loops, method invocation, etc. By using tags on standard XHTML, the results of adapting a page for hookup with the rest of the application retains the structure and parsability that the designers originally created. The original structure is preserved, and conversely, typical design tools preserve foreign tags (generally, ignoring them, maybe even colorizing them distinctively), so we avoid disruption in both directions. (It's a pleasure to be able, as a programmer, to take designer's markup and add the right tags, capitalizing on their designs without disrupting them - and to be able to trade the result back and forth, evolving it without having to retrofit changes again and again. I've done this, on customer projects, and was **not** able to do so when we were using DTML.) The issue about order of tags seems to be a misunderstanding - the order being described was order of _execution_ - precedence of the tags, to serve the programmers purpose. For more information, see the TAL (Template Attribute Language) specification: http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4 The discussion about procedural versus templating language may be based on misuse of terms. I think the issue is block-structured versus page/layout markup. It's common to see templating languages that hookup to underlying programming logic by interspersing block-structured code with page-layout directives. Both in principle and as someone who has used a few of these systems, i think they're fatally flawed for anything more than simple layouts. I know that we *can* accomplish elaborate layouts with such systems - god knows, i've done so. I'm just saying they're unnecessarily hard to unravel, change, and debug - because of an impedence mismatch, where the structuring of one syntax does not obey the structuring of the other. (Recently i posted something equating this intermixing of structural boundaries with undisciplined use of goto in a high-level language - both defeat many of the benefits of clean structuring. This sort of thing is especially galling, eg in DTML, to those of us that came to Zope with an appreciation of Python for its tendency to exceptionally readable, comprehensible code. I also like lisp, particularly for its elementary syntax and susceptibility to programmatic manipulation, but have been won over beyond lisp by python's economies...) Using XML for your language, as i gather HyperTIES does, avoids the structural disruptions, since XML is strict and consistent with HTML. By sticking with HTML, however, we also leverage pervasive expertise - at least being able to use the efforts of the numerous folk familiar with HTML, and in some cases enabling them to do various levels of their own programming hookup with ZPT. There may seem to be ways we restrict our templating language by using HTML, and in some ways, that's right. In fact, that's another, very important benefit, here. The Zope environment provides numerous ways to express elaborate business logic, ways that are much easier to read and process than any markup-oriented language can provide. (These ways include things like web-editable python scripts, standalone external methods, and product methods, as well as SQL methods and so forth.) Markup is best used for presentation - the only procedural logic we want in our templates should be presentation specific, or calls out to tap the results of the application business logic, underneath. Conversely, the business logic should not have to produce presentation - just provide the fodder for it. ZPT sits in this balance, very nicely i think. I haven't been following the conversation very carefully, so don't know whether or not you've gotten acquainted with ZPT - the canonical place is: http://dev.zope.org/Wikis/DevSite/Projects/ZPT Considering the approach of HyperTIES, you may find a lot to like there. -- Ken Manheimer [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 )