Isn't that a little bit backwards?
Usually the app server is on the front line and is compromised first,
especially since usually the app server talks to the database server
on an internal network and the database server isn't available
externally.
Also, protecting the programs on the app server is usually not a big
deal, it's protecting the data that is the whole point as this is
where all company and customer data is located. In other words, if
they make it to the data having access to permissions is the least of
our concerns since they could play with financial data and such...
-David
On May 18, 2009, at 12:28 PM, 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
--
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.
