[Zope] Using Access Rules

[Dennis Allison]

On Fri, 30 Apr 2004, Chris McDonough wrote:

> On Fri, 2004-04-30 at 18:28, Dennis Allison wrote:
> > I want to add some special checking to prevent direct, through the web
> > access to authenticated users who, I discover, can get a second browser
> > window and move around the site from URL independent of access path.
> > 
> > Suppose I have pages stored in a folder structure rooted at /foo.  The 
> > view security permission on /foo/...  requires an Authenticated User.
> > Normally pages are served from /foo/... under programatic control and 
> > additional constraints are applied.  But, if the user creates another
> > browser window and if he/she knows the URL (or the root URL) they can 
> > move about /foo/... however they want by simply entering the URL into 
> > the browser.  (This works because they are authenticated and the 
> > authentication is shared in the browser.)
> 
> True.  Although.  They don't have to open a second browser window, they
> can just type the URL into the original one, no?  Are you doing some
> sort of client-side obfuscation by hiding the URL bar or something via
> JavaScript in the application?

The first round of defense is to kill the URL bar (and rejoice in the
additional screen real estate).

> 
> > An access rule seems to be the right mechanism for this sort of test,
> > but I don't quite understand how to manage the control flow.  I put the 
> > access rule in /foo.  It gets executed when /foo is traversed.
> > Now, it appears that the access rules are executed for side-effects 
> > only.  If that's the case, the way an error message is returned to the 
> > caller is by modifying REQUEST to reference the error message object 
> > and not the object originally specified.  Returning without changing 
> > the REQUEST allows Zope to continue traversing the path.
> > 
> > Is my model correct?
> 
> It's hard to tell.  If you are relying on client-side
> security/obfuscation, you're fighting an uphill battle.  You're never
> going to be able to prevent people from accessing a URL directly.  If
> you aren't, it's possible that you may be "fighting the framework" a
> little bit here and should maybe take a step back and see if there's a
> way to solve the problem using the builtin Zope security model.
>  

The basic problem is simple--consider tests.  We want them hidden until
the test is about to be given and then available.  Answers (for self-test 
exercises) should be available only after the corresponding test has been
taken.  (-:

The current system controls access programatically, but it's possible to 
end-round the programs by typing the URL directly into the browser (after
acquiring an appropriate browser window--one with a URL bar).  It's this 
non-authorized access that we want to prevent.

Any thoughts.