On 1/6/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > > On 1/6/06, Jeff Watkins <[EMAIL PROTECTED]> wrote: > > Kevin, you're absolutely correct. I've forgotten now who asked for > > SecureResource, but this was specifically what was asked for. However, I'd > > agree it does seem slightly counter-intuitive. > > > > I'd propose the following: > > > > * SecureResource decorates any exposed methods (as it currently does) with > > the specified requirements. > > * In addition, __getattr__ checks to see whether the value returned is > > derived from Controller and if so, enforces the requirements specified for > > this SecureResource. > > If memory serves (and I'm pretty sure in this case), __getattr__ is > only called for attributes that don't exist. __getattribute__ is > called for all attribute access, but you need to be careful to avoid > endless loops and whatnot. > > > Another option is to use SecureObject which protects ALL access to the > > object whether exposed or not. > > Ahh, that may be a fair option for people who want to secure a whole tree.
I'm five days behind on list mail and I haven't tried Identity yet. But being able to protect a directory or tree in one step is very important. Otherwise you protect all the methods but forget about one, or don't realize one can be accessed in an unauthenticated manner. Quixote does this easily in ._q_traverse(), which is called on every access to or through the directory. It's also a useful place to set default request attributes, redirect, and other needs the developers didn't foresee. Can TG have an optional hook method in its directory classes for stuff like this? Quixote's has to actually process the URL components under it, but this one would just be a way to raise exceptions or initialize variables for everything underneath it. I assume authorization failure and redirects can be handled by exceptions. -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable)
