Re: Security Checks in API functions

Marcel van der Boom wrote:
> On 21 apr 2009, at 12:44, [email protected] wrote:
> 
>> API functions are always called by something else, so the idea presents
>> itself: why not relegate security checking to whatever calls the API
>> function in the first place?
> 
> I'd actually argue the reverse situation, i.e. put the security check in
> the common place. The API functions are the 'action' handlers, which imo
> should contain security checks, so whoever/whatever calls them does not
> have to be bothered by them (if they dont want to or cant), but it is
> also ensured that the action is properly filtered/protected at all times.
> 
> Is the real problem not in the security checks themselves? If i recall
> correctly they could benefit hugely by caching implemented in the proper
> places, or was that already implemented?

I can see the argument both ways: I have often found the way privileges can be
applied at the data level to be more of a hindrance than a help. The problem is,
 privileges applied to user functions, such as being able to display an object,
do not always map directly onto the lower-level data access privileges.

Take articles as an example. I may want to remove all privileges of viewing
articles through the articles module, i.e. I don't want anyone to be able to use
the articles front-end. That seems like a simple privilege (and it should be).

However, the underlying data in the articles could still be accessed through
other modules that pull the data via the articles APIs or hooks.

The roles module is another example: if I want to stop people from using the
roles front-end screens to view user data, then that same privilege will prevent
 access to full names of users when displaying in, say, xarBB.

In conclusion: privileges at the different levels from the lowest data level to
the front end interfaces do no necessarily (and often do not) map directly onto
each other.

-- Jason