> On 27 October 2012 06:53, klas berlič <klas.ber
...@gmail.com> wrote:
> > JSON means current implementation is more complex (2 ACLs says enough),
> less
> > maintainable (more API, 2 ACLs) and its performance is _____ (insert bad
> > word here) - checking permissions using php is simply a magnitude slower
> > that when doing it using relational database.
> I beg to differ, and so do a lot of people trying to solve the same
> problem.
> > Please note performance claim applies to the real ACL part, not to its
> view
> > surrogate part that was invented just because real ACL was so badly
> > performing.
> Bollocks. Talk to anyone who has design access control and they'll
> tell you that the "challenge" vs "give me a list of what I'm allowed
> to do" and they'll tell you they are two completely different
> strategies. The are all under the umbrella of access control ("real
> ACL" and "surrogate" are just things you are making up).
> > "I wasn't a big fan of Klas's approach because it meant that the poor
> old
> > component developer had to set up too much data in the database before
> > anything would work."
> > Not really true,
> It is true that I'm not a big fan of your proposal :P
> > perhaps you got it confused with some other proposal.
> > There are zero database actions needed on the developer side, all
> > permissions are stored in the permissions table and everything works
> trough
> > API.
> I'm struggling to work out how your system is designed without
> database actions. Maybe you can explain how that works?
> > Even Joomla database structure would only need to be minimally changed
> and
> > even more - all drop parts can be skipped for first version to maintain
> > backwards compatibility :
> > drop JSON rules in the assets table
> > drop view permission columns
> > drop viewlevels table
> > add permissions table
> > add asset_id columns to extensions,modules,menus
> > What I'm proposing with my (working) proof of concept is to drastically
> > reduce API and simplify things to the point where it can't be simplified
> > anymore.
> phpGACL actually does that (but not as a flat matrix). But it's a
> "challenge" system. It's not good at querying a list of what you can
> do (even Mike agrees with that, and acknowledges that it's a difficult
> problem to solve).
> > The whole API relevant to developer consists of 2 functions:
> > one to check permissions for a single action (and this includes view
> action)
> > isUserAuthorizedTo($userId, $action, $asset)
> That's the "challenge" - easy peasy and not overly expensive in either
> JSON or 3rd normal form (inheriting in 3rd normal form though, that
> gets fun).
> > and another one to auto insert query into multiple items queries
> > insertFilterQuery($query, $joinfield, $permission);
> More or less the same "strategy" we are using now.
> > so instead of having
> > ->where('access IN ('.$levels.')')
> > in query, you would just do
> > MAccess::insertFilterQuery($query, 'e.asset_id', 'core.view');
> Right, there's nothing wrong with that function, but the devil is in
> the detail in what it's doing to the query. Without those details
> it's hard to judge one way or the other.
> > And this is the really simplest comparison example on the joomla side,
> try
> > checking multiple items for edit permission in single query in Joomla if
> you
> > can.
> It would be a trivial exercise to wrap a method to be able to do that.
> Whether it's efficient or not is another matter.
> > As Herman mentioned performance - it wasn't just a guess, I did some test
> > and (view) performance degradation was 10% and with further optimization
> it
> > could be improved further, while performance on the other actions is
> highly
> > increased, but I have no actual numbers (but again, try checking edit
> > permission on 1000 items via joomla vs. simple query).
> So, the thing is, I'm personally not too interested in saying there is
> only one way to store your "rules" - I don't care if you want to use a
> CSV, phpGACL, a flat matrix, Active Directory or LDAP. That's the
> point of the authorisation package. It's there to establish an
> interface for access control challenges and "you" work out how the
> rules work. What it probably lacks is an interface to get a list of
> things you can do - I'm enjoy talking about how to define that
> interface.
> Whatever the case, I would try to avoid a use case where I had to
> check 1000 items against an "edit" permission. As to whether the
> query is simple or not, again, I'd have to see how many joins you are
> doing and how well you've indexed the data.
> > Latest version I have (not public, but I can make it so if there is
> > interest) is compatible with Joomla 1.7., it would be fairly easy to
> update
> > it to the 2.5, for 3.0 widget javascript would need some more work.
> Joomla CMS version X is out of the scope of this discussion. However,
> I am interested in generic strategies. If a new strategy proves
> useful, any Platform Application (include the Joomla CMS) can
> potentially use it.
> > If anyone is interested take your time and check the video and slides
> from
> > jab11 ( http://forkito.org )
> Ignoring the obvious antagonism (one hopes for theatric effect):
> "Simple matrix of groups and actions" - there are numerous articles
> about why matrix style access control is severely limiting. The
> winnowing of those matrices is really not easy and inherently
> restrictive (we don't do it that way any more). Mike's documentation
> on phpGACL covers matrix theory pretty well, including its limits.
> "Lower level always wins" - well, whatever. That's not the "right"
> way, just a "different way" (doesn't mean the ACL is poor or
> excellent). That's why I set up the authorisers in the authorisation
> package so you could change the rules depending on your use case. The
> same goes for "assigned beats inherited". It's not necessarily
> better, though it may be in some cases, it's just different. The CMS
> access control was based on folder permissions - something developers
> would be familiar with (again, not necessarily "better", just
> "familiar"). I will say though, that your rules are suited to the
> limitations of matrix style access control, and there's nothing wrong
> with that.
> "No code repetition" - hard to know what you meant in the absence of
> slide notes.
> You don't like JSON encoding. So what? Who are you to judge it's a
> crime :P It does disable database relations on challenges, but not
> view access. However, you actually do something naughty here (slide
> 27) and equivocate "viewing" with "challenging". You wouldn't do
> "view" in JSON form and there were never any plans to do so. Implying
> that Joomla uses JSON to check the "view" permissions was rather
> dishonest. Same with slide 28 - I absolutely agree with your
> statements, that's we we didn't design it that way (but you imply we
> did).
> So, ok, we get to code examples in slide 35, 36 et al but all you show
> is your API to use. There's no data theory to back up how you've
> designed the system (schema, queries, etc). I'd be happy to compare
> the current access package with yours if that information was
> available.
> > Not that I expect this to happen as one or two people in charge would
> have
> > to admit their mistakes, but ->
> If you can give me chapter and verse as to where it established that
> your way is the only right way, I will happily concede ;) (said with
> ample tongue in cheek) Let's be honest Klas, we are really talking
> about different strategic approaches to a very broad, and common,
> engineering problem and which one you prefer. There is no single
> right way of achieving an acceptable result. I accept and honour the
> fact you don't like the way it was implemented, and interpret what is
> needed differently.
> > If either platform or CMS is seriously interested I can fairly quickly
> > update and contribute this code for one of the next framework/CMS
> releases.
> Now we are talking. How about you first outline the strategy involved
> (don't just tell us to replace this API with that - tell us how your
> API works under the hood). I'd certainly be interested in unpacking
> what you've done at the technical level, but you need to be the story
> teller :)
> Regards,
> Andrew Eddie
