[Zope] Using Access Rules

Dennis Allison allison at sumeru.stanford.EDU
Sat May 1 02:24:40 EDT 2004

Thanks for the thoughtful response.  We use a mix of DTML/Python/Products
as needed.  It's proven to be a fairly fast, effective, and stable
approach.  We've handled whatever performance issues there might be by 
simply using big cheap iron.

I think we will need to do a custom product.  One thing I did not mention 
is that the materials to be protected are maintained in the local file
system and are actually accessed through the LocalFileSystem product.
The systems architecture limits the number of access points.  A
specialized product which has no URL access would serve our purposes,
provide the security we want, and may even improve performance.  Jaime
suggests something along the same lines.

For the moment I have found a couple of hacks that provide some limited 
protection although any self-respecting blackhat could slip through.
We'll implement them immediately and then do a product.  (The product 
shouldn't be much code, but it will need to have the *right*
primitives--and that's the hard part.)

Thanks for your help.

On Sat, 1 May 2004, Chris McDonough wrote:

> On Fri, 2004-04-30 at 22:44, Dennis Allison wrote:
> > I think I was confused and therefore confusing.  Let me try to explain
> > again.  I am trying to control the publishability (that is, visibility) of
> > objects A, B, and so forth.  Object A has a URL /z/y/x/A and is legally
> > referenced only from URLs /p/d/q/R and /p/d/n/S and then only in some
> > (computed) circumstances.  For our purposes let's assume that references
> > from R and S can be guaranteed legal.  All other reference are to be
> > disallowed, even if the user holds the appropriate Zope permissions.
> You could build a graph, which could be a fully predefined mapping from
> each "protected" object path (you'll want to think of this in terms of
> object path rather than URL as objects can be accessed via more than one
> URL) to a set of prerequisite "protected" object paths, maybe in a
> Python Script.  As the user visits a protected object, the prerequisites
> for the object would be checked against a list of visited paths kept in
> his session, and if they aren't met, an error would be raised.  If they
> are met, the path to the object is would be entered in the same visited
> path list in the session and he would be allowed to see the rendered
> object.  And so on.  The graph itself could be mutated when the user
> "finishes a test" and can see the answers so they weren't allowed to go
> back to the test questions and submit them again.
> But if you use sessions, you are implicitly depending on state that is
> kept on the browser, so this isn't very secure (if they click fast
> through the test, get to the answers, read them, close the browser and
> reopen it to get a different session, they could just take the test
> again; you can probably come up with other black hat scenarios).  It
> would be better to associate the state with the username on the server
> side instead of associating a state with a session, but there is nothing
> really built in to Zope that will help you do this without some custom
> likely-non-TTW code.
> All that said, building these granual per-path state graphs will likely
> be tedious and whoever does it will be prone to error.  There are
> actually probably a lot fewer states than this graph might indicate. 
> You should try to find the states implied by the application, and maybe
> instead of using object paths, use state names like "taking test" and
> "finished taking test" and map each one of those names to a container
> that is allowed to be accessed while the user is in that state, which
> would imply that the user could also see the contents of the container. 
> Or something like that.  It's all pretty application-dependent.
> If you do this, you're essentially replacing Zope declarative security
> with a custom state-based model, so there are really no sane declarative
> security settings for the domain objects.  You'll probably end up making
> them anonymously viewable in the ZMI and rely on your app code to do the
> security checks.
> All of this might be the right thing to do in your case as you're under
> a deadline and it sounds like you're developing this using mostly TTW
> code, but it seems like a lot of work to me.
> - C

More information about the Zope mailing list