as a devils advocate here I don't see any mention of hackers, after all this is security. for instance I think it is harder to override security built into the code than security external like a database. A database can be compromised and there goes your security.
Adrian Crum sent the following on 5/17/2009 10:04 PM: > --- On Sun, 5/17/09, David E Jones <david.jo...@hotwaxmedia.com> wrote: >> If I understand correctly what you are describing above it >> is simply >> record level permissions. And yes, I agree that is a >> common >> requirement that we've discussed quite a bit. I'm worried >> I'm >> misunderstanding though because I'm not sure how that fits >> with >> comment... > > It fits into the design objective because it takes the record-level filtering > out of code and puts it in assigned permissions. Isn't that one of the > objectives? Remove the security checking that is embedded in code and put it > in the database where an administrator can assign it to a user. > > Instead of hard-coding record-level permission checking inside some other > service, extract the record-level permission checking code, make it a > service, and assign the service as part of a user's permissions. > > It's clear we have disconnected somewhere. The existing entity engine doesn't > know about security. It works with not-logged-in users and anonymous users > and whatever else comes along. I'm not suggesting we change any of that. Keep > it all the same. But add the ability to restrict records based on the user. > If there is no user, then it does what it has always done. I don't know how > else I can say it. *shrug* > > -Adrian > > > > > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator.
