If a hacker gained access to the database in the existing design, the
same would be true.
-Adrian
BJ Freeman wrote:
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 <[email protected]> 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
