Re: Security Checks in API functions

"[email protected]" <[email protected]> Tue, 21 Apr 2009 13:32:24 +0200
Newsgroups gmane.comp.cms.xaraya.devel
Organization Xaraya
Message-ID <[email protected]>
Marcel van der Boom wrote:
> On 21 apr 2009, at 12:44, [email protected] wrote:
> 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.
> 
A common comment you still find in places in the code above security 
checks reads something like "do this as early as possible". You clearly 
have an access checking situation at the level of GUI functions, because 
that is where you are interacting with the user. I don't see any way of 
getting around that.

I find it easier to argue that the allowability of an action depends on 
its context: if the calling function has decided it's OK to create, then 
the action handler, which has no knowledge of the context, should just 
do it.

You do however raise the point of filtering, which would best be located 
  in the code executing the action. Filtering becomes an issue where API 
functions return content, sort of a generalization of the getmenulinks 
example I gave.

> 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?
> 

mikespub iirc set up same page caching a long time ago. I actually 
implemented caching across pages in Jamaica, in other words you pull 
your irreducible privilege set once and then carry it around with your 
session. iirc it got something like a 15%-20% speed improvement, but 
it's commented out atm as I haven't yet settled on the correct way to 
deal with the situation of how to adjust the active users' privileges 
when the privilege tree itself changes.

So yes that is one problem, but another is clearly that we're often 
checking the same thing several times when one time would suffice.