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?
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. - C