With so many options, I’m unsure what might be a “best practice here”. I have a module (though that fact is probably irrelevant) that has some public interfaces (views) and some that are administrative in nature so I need to selectively check to see if the current user belongs to a certain role as required by the action being requested. It would be nice to easily add meta information to the action method in the handler that “declares” itself as requiring a certain role (and this is not intended to be a universal solution, just trying to meet the clients need).
I’ve thought about an interceptor but then I have to litter in alot of conditional code checking for module and action, so maybe a prehandler action and prehandler_only setting, then of course I could just drop in a snippet of code at the top of any action requiring certain permissions.
Just casting this out to see if anyone has a pattern they prefer and why. Or maybe even something in the wiki that I missed that talks about some options?
Thanks,
Mike Craig
I don’t know if there’s any “official” best practices per say… but I have solved event-based security in the past with white list/blacklists and a preEvent interceptor. The ColdBox security interceptor would probably do the same
I do like the idea of simply annotating event handlers, but those annotations might be difficult to get to from an interception point.
One idea that I think would work well, but I’ve never tried would be to create an AOP advice that checks for permissions and then bind that advice to any methods with your annotation. That way, any method annotated with requiresAdmin=true would get wrapped in a “before” advice that would throw an error or redirect to login if the current user of the site didn’t have those privileges.
Check out the “annotatedWith” binding DSL:
http://wiki.coldbox.org/wiki/WireBox-AOP.cfm#Aspect_Binding
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Mike. Let me give you another option. AOP.
This is the exact reason why AOP approaches exist. To help you build cross cutting concerns around your already built code.
You can use a preprocessing interceptor or build a complete AOP aspect that checks your desired annotations.
Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano
Well, since both of you pointed out AOP as a good solution for this kind of need, so be it. So, for my first CB project, slowly but surely, perhaps even inevitably, I’m hitting every feature the framework makes available. Note for new comers to the framework…stick with it and don’t be frightened.
Thanks guys,
Mike
Good advice to the newcomer... The last few weeks I have had to up my vocab significantly... Then I have to program with it.
I think I will be asking lots of silly questions.
Good news... I think my and my co-programmer will be at cb boot camp and CFO 
maybe that will help get through the teething
As Brad mentioned earlier, there’s not an “official” best practice… in some cases it depends on the details of the business rule behind the security validation.
Some are very black and white as in the user permissions either have or doesn’t have access to a certain event/resource. For situations such as this preEvent hanlder with white lists or config settings work really well. As Luis also mentioned AOP is perfect for that, some folks opt to do the validation at the service level (say your app also exposes services to other parties not just via the controller) so AOP advice to those service calls helps you maintain your security code (only downside is your domain is now aware of current user which is seen as breaking encapsulation).
I’m currently working on an app where permissions are either “constrained” or “unconstrained”, meaning the user either has the permission to access an event/resource (unconstrained) or there’s an additional business rule to check (constrained) such as are they one of the assigned owners of a particular record set. In the constrained scenario I have to pass an expression to the permission check along with the permission to validate whether or not the user has rights to edit and he/she is assigned to that particular instance. So for that I’m simply doing my permission check within the controller since I need to have the persisted instance loaded in order to pass the boolean expression check into the validation method.
I can elaborate on this further if you like to explore this option and show some code examples… and I’m going to reinforce what others have said, ColdBox has a really nice built in security feature that’s worth looking into if it fits your app’s needs.
Best,
Brad, this would make a great afternoon talk BTW…particularly an example of AOP and cross-cutting code implementation.
Mike
Mike, thanks for the suggestion. Is there anyone who wants to volunteer to do a quick demonstration in a Connection meeting.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Brad,
I would be interested in co-presenting some of this, however I’m currently “out” on paternity leave and probably won’t be able to commit to anything for the next couple of weeks. I can ping you once the dust settles here…
Best,