> I have some questions regarding best practices when implementing > role based access control (RBAC). I have been playing with > CApp::Authentication and Authorization, and they both do basically > what I need.
*** Me too. I have three sub-businesses. Let's call them A, B, C. I want to have access to all of it, but I want my managers to only have access to their particular piece. Here's more or less how I did it. BTW, it recently broke for unknown reason, and I havent' gotten around to troubleshooting. CApp:Authentication has a notion of "drivers". I wrote a multi-DB driver that can look in a set of authentication databases. I have a "users" mysql database at my global level, and another "users" database in each subbusiness. When somebody attempts to log in, the multi-auth driver tries each database in turn. If it successfully authenticates against the "global" database, that user has privs for all the sub-businesses. Each line in the "users" database has a set of "permissions" flags, which correspond to things seeming to permission as I coded. In line with the code are statements in the form if( getpriv( user, business )){}. That way, I have a permissions system with much finer granularity than Capp::Authorization, which I do not use at all. - Jerry Kaidor ( je...@tr2.com ) > > Here's the skeleton I came up with - > > https://gist.github.com/33d23edf8fa2c0f48dc0 > > My question is really, what's the best way to go about separating > functionality in a CApp based application? > > A practical case I am looking at right now is that I have form that > is used to manage user data. There are 3 roles - User, Manager, and > Admin. Each one has the types of permissions you'd expect (User can > manage himself, Manager can manage his Users, Admin can do anything). > > I was thinking of the best way to build this form and control actions > cleanly and compose this form using 3 different runmodes that are > increasingly restrictive. > > For example, the User form calls the "user" runmode, and returns the > form content. The "manager" runmode takes the output of "user" and > adds some stuff to it. The "admin" runmode might take the result of > the "manager" runmode - which would also include what the "user" > runmode provides...and so on. > > Ultimately, my goal is to get away from nasty frog boiling "if" blocks > controlling authorization and rely on composable functions (i.e., > runmodes or modules) that will cleanly give me what I would like using > the runmode level protection that CApp::Authorization provides you. > > I've searched around and banged my head against this pretty hard, so > any thoughts or resources would be appreciated. For all I know, this > might be a bad idea. But I am really just looking for the best way to > create an access controlled system as cleanly as possible. > > Thank you, > Brett > > ps: I noticed that even if POST_LOGIN_RUNMODE is protected via > CApp::Authentication, the check seems to be ignored immediately after > login. I am not sure if this is a known issue or that there are some > callbacks happening in the wrong order. This will happen in the gist I > linked above. > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################