RE: [Zope-dev] (no subject)

2000-10-14 Thread ralf . herold

Hello Dieter, dear list readers,

I recently asked how to read in and render the contents of 
an external file, which doesn't work anymore using 
Zope 2.2.2 an LocalFS' xxx.read(), and You responded that

 The quickest solution for you would be an external method
 that gets the file, performs the "read" and returns the result.

Now I use in an external method fsreadin a .py-module with

import sys
def readinfile (self, html):
"""Ralf Herolds way to read in local file objects."""
file = open(html, "r")
filecontent = file.read()
file.close()
return filecontent

which is referenced in a DTML method by 
dtml-var "fsreadin('/tmp/var/thewantedtext.html')".

It works, but I almost cannot believe that this is that 
simple - am I missing something, is security a concern?

Thanks for answering, Yours. Ralf Herold
mailto:[EMAIL PROTECTED]  http://www.knm-poh.charite.de/ 

 -Original Message-
 From: Dieter Maurer [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, October 04, 2000 1:46 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Zope-dev] (no subject)

 In earlier Zope versions, a method without a permission meant
 "can be used freely". Now, it means "cannot be used via DTML/URL".
 


___
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] New ZPatterns documentation on the Wiki

2000-10-14 Thread Phillip J. Eby

There is a new document on the Wiki which explains in excruciating detail
how triggers/rules work in ZPatterns:


http://www.zope.org/Members/pje/Wikis/ZPatterns/HowTriggersWork

I have also now completed the SkinScript reference documentation at:


http://www.zope.org/Members/pje/Wikis/ZPatterns/SkinScriptSyntax

In addition to a detailed definition of all SkinScript statements,
variables, and syntax, the reference includes 19 short "real world"
SkinScript examples ranging from very simple to very complex.  Examples
include data movement to/from SQL and ZCatalog, as well as other
Specialists, and various kinds of "alert"-type triggers.

Please note that the SkinScript syntax described is "slightly ahead of its
time" in documenting a few features that are only available in an as-yet
unreleased ZPatterns.  I'm holding up the release of 0.4.3 for additional
documentation and I'm also waiting on Ty to get a LoginManager 0.8.8
release together, as there were some changes that had to be made to LM for
compatibility with ZPatterns 0.4.3, relating to my recent addition of
ZClass support for PlugIns (yay!).

Feedback on the above documentation is welcome.  Thanks.

  _
   _/__)
___/


___
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] Inconsistent behaviour in Zope's constructor security check?

2000-10-14 Thread Stephen Simmons

I have just concluded an epic two day struggle with Zope's security
machinery. I think I've won, and wanted to find out whether anyone else has
had similar problems.
I had defined a Python product that worked very nicely. I was able
to add and delete my objects and edit, copy and export them perfectly well.
But when I tried to rename, paste or import them, I got an exception saying
that "The object X does not support this operation".
It appears that security checks for permission to add an object to a
Folder is done differently by the Product Add machinery and the CopySupport
machinery that paste/rename/import use.
I had defined my constructors slightly unconventionally in
__init__.py. Redefining the constructors more normally solved my immediate
problem, but it doesn't remove the source of Zope's inconsistent behaviour.
More details of the diagnosis are at the end of this email, for those who
are interested.

Is this something I should put in the collector?

One happy result of this mess is that I am now on a first-name basis with
about 80% of the Zope source code!

Stephen
___
Stephen Simmons, [EMAIL PROTECTED]
HealthArena B.V., Amsterdam, The Netherlands
phone +31 20 486 0555; mobile +31 6 1505 3086; fax +31 20 486 0559

Problem copying/pasting and renaming


I was able to create new instances of my Element class, but whenever I tried
to rename, cut/paste or import the objects, _verifyObjectPaste() in
CopySupport.py raised a Copy Error (The object X does not support this
operation).

_verifyObjectPaste() performs three checks:
(i)  The container is happy having an object of this type being pasted into
it
(ii) The user is allowed to create new objects of this type
(iii) The user is able to access the object being pasted or renamed

All three conditions were true, so there is no reason why renaming, etc
should be prevented. Especially when I could create objects as desired
through the management screens.

Solution


The problem was traced to the unusual way I had defined the constructors in
__init__.py and the class's module. It appears that
getSecurityManager().validateValue(meth) does not exactly duplicate the
check done when adding a product instance.

Originally, I removed the constructor definition tuple from __init__.py:
  def initialize(context):
   """Register Element"""
   context.registerClass(
PlatformElement.Element,
constructors = (PlatformElement.Element), # Specified indirectly!
icon = element.gif
  )

and put it at the end of my class definition module, PlatformElement.py:
  class Element(Folder):
...

  def manage_addElement(self, id, name='', title='', REQUEST=None):
  """Create an Element"""
  ...

  Element_constructors = (
   ('manage_addElementForm', HTMLFile('Element_add', globals())),
('manage_addElement', manage_addElement),
  )

In this case, check (ii) was failing at line 390 of CopySupport.py when
trying to validate the constructor
manage_addProduct/HAPlatform/manage_addElementForm.

The problem was fixed by changing the constructor definition to the more
conventional form:

In __init__.py:
  def initialize(context):
   """Register Element"""
   context.registerClass(
PlatformElement.Element,
   constructors = ( # Specify constructors explicitly!
PlatformElement.manage_addElementForm,
PlatformElement.manage_addElement,
),
 icon = element.gif
  )

In PlatformElement.py:
  ...
  manage_addElementForm = HTMLFile('Element_add', globals())

  def manage_addElement(self, id, name='', title='', REQUEST=None):
  """Create an Element"""
  ...

While this fixes the problem, it leaves unresolved the question of why
Zope's security machinery was happy using the original constructors but
barfed when checking whether it could use them.





___
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 )