[Zope] Re: Zope Question

2000-09-26 Thread Chris McDonough

- Original Message -
From: "Ryan Booz" [EMAIL PROTECTED]
To: "Comp Ed List" [EMAIL PROTECTED]
Sent: Monday, September 25, 2000 3:03 PM
Subject: Zope Question

 Hey gang,

 I'm posting this question here because I know a while back some people
 had mentioned they were using Zope.  I'm trying to start using it,
 getting used to the DTML and all the other stuff.  I can get it running
 with my Apache server, and that's all well and good.  But I have these
 two questions which I can't seem to find answers to in current Zope
 documents and help.

 1.  How do I get the server process to run as a daemon?  I've tried the
 one script for an rc process I found on a site, but my server just hangs
 and I never get a command prompt back.  All other processes I've ever
 run at startup are either designed to be daemons, or have a specific
 switch to add to the program name.

Removing the -D (debug) switch from the z2 line in start.py will cause Zope
to release control of the terminal from which it was started.

 2.  OK, this is kind of two part.  First, where does Zope actually store
 all of the directories and files you create for a site.  If I have a
 fake directory as the "trigger" for the persistent CGI process, than
 where does it actually store this pages I'm creating?  As an example,
 following the install instructions that comes with Zope, I've set Apache
 to send every request for /zope to the FastCGI process running in the
 background.  That directory does not exist in my htdocs directory.
 Where is this stuff going?

In the "ZODB" (Zope Object Database).  See
http://www.zope.org/Members/mcdonc/HowTos/gainenlightenment for
some nuggets.  This is a tough one to wrap your head around when you first
get started.

 Two, can I get Zope to answer the general requests for a site (like
 www.bms.school my internal server and fake domain.)  Rather than having
 to specify a directory, it would just send all requests to Zope.  But to
 take that one step further, if I had user accounts set up with the
 /~username convention, would this stuff be able to pass through Zope and
 actually go to those directories?  I don't think I'm making this
 question clear, but I don't know how else to state it right now.

See the SiteAccess product on Zope.org

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-dev )

[Zope] RE: Zope Question entry: Security changes

2000-06-29 Thread Brian Lloyd

 Description:  (I posted this to zope-dev, but havent seen an 
 answer yet. Im adding it here so it doesnt get forgotten)
 some questions raised by 
 Firstly, how does the presence of 
 __allow_access_to_unprotected_subobjects__=1 in a class 
 affect access to attributes in derived classes? Does it 
 affect the whole instance, or just attributes of the class 
 that includes it. In the following example I know subobject_2 
 is accessible, but what about the others?
 example snipped


(sorry not to get back to you earlier on this) 

The security assertion is generally tested on instances, so if 
an instance has the assertion in its class (or any of its base 
classes) then it is effective for all of the base classes of 
that object.

 Secondly, I am confused that there have not been any security 
 changes in ObjectManager.py and PropertyManager.py. As I 
 understand it, the subobjects that they manage (ie properties 
 and folder items) now fall into the inaccessible-by-default 
 category. What am I missing?

Actually there has been a change: the security assertion is in 
SimpleItem.Item (which acts as a base class for most, but not 
all, Zope objects). This is why "dynamic" attributes such as 
properties continue to work as before.

Your first reaction might be (as mine was) "well, doesn't that 
just put us right back where we were before?". Not quite. What 
has been done is a first step to changing the policy to deny-
by-default rather than allow-by-default. Having the assertion 
in the Item class has the effect of:

  o allowing access to properties and some other kinds of 
attributes that are not currently explicitly protected, 
needed for backward compatibility

  o DISallowing access to certain other things that the old 
security rules would have allowed - for example under the 
old rules alone it was possible to get to the func_globals and 
other attributes of methods that you really shouldn't have 
access to. We had to handle that with special cases, which 
was painful and error prone (and only worked for problems that 
you knew about). 

The new policy with the security assertion allows us to keep access 
to properties and things we _need_ access to for backward 
compatibility, but also has the effect of protecting things like 
method attributes and other (possibly unknown) bits that should be 
off limits (a method would need a security assertion of its own for
those things to be accessible). 

While this is not totally perfect and still requires you to be 
careful about protecting attributes of base classes, it is better 
than it was before and a first step on the road to where we want 
to be that shouldn't cause too much angst among users and product 

Hope this helps - I'm going to reformat this a little and add 
it to the Product author guide.

Software Engineer  540.371.6909  
Digital Creations  http://www.digicool.com 

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-dev )