[Zope] Using Access Rules

[Chris McDonough]

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