On 8/26/07, Cliff Hirsch <[EMAIL PROTECTED]> wrote: > > I was waiting for you to chime in here. Just re-read your RBAC chapter in Pro > PHP Security (AWESOME BOOK, BTW). Nice Hamptons beach reading. Its that or > Clive Cussler. > > As I think about this, the problem is all the "locations". A front-end > controller can consolidate or automatically synthesize and manage locations. > But there could be soooo many. And it seems to me the presentation layer needs > a heck of a lot of if statements to hide sections, links, buttons, etc. if you > want to hide unaccessible stuff instead of a simple "not authorized" msg.
That depends on your information architecture (how interconnected is everything, really?) and how granular your access policies are. But it's true what you say--there's a _lot_ of checking to see if the user can do this or access that in any reasonably complex system. I just looked at a typical calendar view and counted around 360 separate access control checks. It's extremely important that these checks be as inexpensive as possible--you obviously don't want to hit the database or ldap directory that many times. But that doesn't mean you have to write a bunch of conditional statements. Access control is, ideally, itegrated into your framework. When you fetch a collection of objects to populate a navigation menu, the ones that the user doesn't have access to shouldn't be sent to the presentation layer in the first place. That "embeddedness" is the main reason why we didn't include an actual RBAC system in Pro PHP Security--the sample code would have had to implement an entire mini framework. -- Chris Snyder http://chxo.com/ _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
