Re: [Openinteract-help] Separate security tables?

[Chris W. <ch...@cw...>]

Vsevolod (Simon) Ilyushchenko wrote:
> Thanks for looking at the setter method. I assume the fix is 
> straightforward (I'd like to start using it asap). You also have a note 
> about this in the SPOPS man page:

Yes, it's pretty straightforward. It's in CVS now, but I plan on 
releasing 0.80 in the next couple days (Fri/Sat probably, since 
Thu is a holiday). One bonus I added: you can override an 
internal method and generate your own getter/setter/clearer methods.

I updated the docs as well, thanks for the pointer.

> Paranoia. I had a home-grown security system (SPOPS without steroids :) 
> which at first utilized a single table. A couple of times bugs in the 
> persistence code screwed the whole table up, so I broke up the security 
> info into separate tables. Then yesterday I was changing something in 
> the spops_security table on the mysql command line and made a mistake 
> again. So the old fears flared up.

Well... the code ain't perfect, but some folks have been using 
SPOPS on fairly large projects and AFAIK never had a problem like 
this. I think one of the keys with object-level security is to 
use it sparingly. Most of the time application-level security 
will suffice -- normally if a user can edit one record she can 
edit another.

Another approach is to use a hierarchical security model. That 
is, each object has some characteristic that places it on a leaf 
in a tree. Rather than defining security for each leaf we define 
it on branches to be inherited by other branches and leafs. Just 
like a filesystem. This way doesn't generate many security 
records and is fairly easy to check and cache the results.

> AFAIU, you call this potentially bug-ridden because this assumes that, 
> if I put this in a superclass, each subclass will have to process its 
> config before next class's global_security_object_class() is invoked?
> I'll give it a try.

It's potentially bug-ridden because I'm assuming everything uses 
'global_security_object_class()' properly. I *think* this is so 
but I'm not certain, and it only takes one exception to screw 
everything up -- for instance, caching a security class name for 
one SPOPS class, using another SPOPS class, and then using the 
cached class name. The trick I used previously (resetting the 
table name in 'global_security_object_class()') would fail 
miserably and it could be difficult to sort out.

Good luck!

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.