Re: [Zope-dev] restrictedTraverse

2002-05-16 Thread Stuart Bishop


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

2002-05-16 Thread Adrian Hungate

 
  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

2002-05-16 Thread Don Hopkins

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

2002-05-16 Thread Chris Withers

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

2002-05-16 Thread Eron Lloyd

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

2002-05-16 Thread Nicola Larosa

[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

2002-05-16 Thread Nicola Larosa

[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

2002-05-16 Thread Ken Manheimer

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 )