Basic Event Security in Model-Glue Applications
To anyone who has not yet breached the subject of model-glue event security, it can potentially be confusing at first, so I thought I'd share my approach to it in case it helps save someone a little time.
Understanding and being able to visualize the life-cycle of a Model-Glue event is a prerequisite to really grasping event security, so let me share my take on what a brief overview of that life-cycle is.
So, now that we know the flow of a named event within Model-Glue, it's time to add in a security check to make sure the current user has permission to execute that event. In my scenarios typically I have private and public events (those that can be executed without being logged in (such as the 'login' event itself), and those that require previous authentication (such as 'manageAccount')) and events requiring a specific role (such as viewing billing reports).
What we will effectively do is slide in some functionality between the event request and the execution of the event itself by leveraging OnRequestStart. This functionality will either allow the named event to pass on through OR redirect the user to the event we want them to arrive at. For instance, if they attempt to access an event that requires login and we intercept that event, we'll redirect them to the login page.
Here's the process for putting the named event check functionality in place:
1.Create a function that checks the current event name against a given list of event names;
2.Register that function to be called at 'onRequestStart';
3.In the Modelglue.xml file, create an event called "modelglue.OnRequestStart";
4.Within the modelglue.OnRequestStart event, register named results and provide appropriate redirection values;
What's going to happen then during the event life-cycle is that, before the actual named event executes, any controllers listening for the 'onRequestStart' message will execute their functions. One of those functions will have the sole job of verifying that the event being requested is allowed to be called in the current session state (logged in, not logged in, is an admin, etc.) If the event is good to go, the function is finished. If the event should NOT be allowed to execute, the function will set a model-glue named result. Next, since we defined an event called modelglue.OnRequestStart, that event is evaluated before any named events. The only thing we have defined for it to do is to look for specific named results and if one of them is found, perform the appropriate redirection. If none of the results being watched for are present, the named event executes normally.
I know at this point there must be a lot of questions on how to actually implement what I've been describing at a high level, so here are the same steps with snippets you can use:
1.Create a function that checks the current event name against a given list of event names;
In our scenario, let's assume two things: that we have events we want to require security, and events that we want to require that the person logged in also be an administrator.
2.Register that function to be called at 'onRequestStart';
3.In the Modelglue.xml file, create an event called "modelglue.OnRequestStart";
and
4.Within the modelglue.OnRequestStart event, register named results and provide appropriate redirection values;
As with anything Model-Glue or OO, there's always greater levels of detail to be expounded upon, but these snippets are more for illustrative purposes than actual 'out of the box' code, so I'm leaving a lot of the details to you. Such as where you should really store your lists of named events, or how your user object is always present, empty or populated, regardless of whether or not the user is authenticated, etc.
Anyway, hope this helps get somebody over the hump!
Understanding and being able to visualize the life-cycle of a Model-Glue event is a prerequisite to really grasping event security, so let me share my take on what a brief overview of that life-cycle is.
- A request is made, notifying model-glue to execute a specific event (eg; http://www.somesite.com/?event=fireinthehole )
- MG looks in its modelglue.xml file to find out what messages to broadcast to listening controllers ( <broadcast><message name="blowitup" /></broadcast> ) for the 'fireinthehole' event
- controllers listening for the "blowitup" message execute their corresponding functions ( <controller name="bombController" type="controller.eodGuy"><message-listener message="blowitup" function="BlowInPlace" /></controller> )
- MG executes any relevant result actions (acts as an 'if' statement almost) if they exist
- MG renders any views that are defined for this event
- The event lifecycle is over.
So, now that we know the flow of a named event within Model-Glue, it's time to add in a security check to make sure the current user has permission to execute that event. In my scenarios typically I have private and public events (those that can be executed without being logged in (such as the 'login' event itself), and those that require previous authentication (such as 'manageAccount')) and events requiring a specific role (such as viewing billing reports).
What we will effectively do is slide in some functionality between the event request and the execution of the event itself by leveraging OnRequestStart. This functionality will either allow the named event to pass on through OR redirect the user to the event we want them to arrive at. For instance, if they attempt to access an event that requires login and we intercept that event, we'll redirect them to the login page.
Here's the process for putting the named event check functionality in place:
1.Create a function that checks the current event name against a given list of event names;
2.Register that function to be called at 'onRequestStart';
3.In the Modelglue.xml file, create an event called "modelglue.OnRequestStart";
4.Within the modelglue.OnRequestStart event, register named results and provide appropriate redirection values;
What's going to happen then during the event life-cycle is that, before the actual named event executes, any controllers listening for the 'onRequestStart' message will execute their functions. One of those functions will have the sole job of verifying that the event being requested is allowed to be called in the current session state (logged in, not logged in, is an admin, etc.) If the event is good to go, the function is finished. If the event should NOT be allowed to execute, the function will set a model-glue named result. Next, since we defined an event called modelglue.OnRequestStart, that event is evaluated before any named events. The only thing we have defined for it to do is to look for specific named results and if one of them is found, perform the appropriate redirection. If none of the results being watched for are present, the named event executes normally.
I know at this point there must be a lot of questions on how to actually implement what I've been describing at a high level, so here are the same steps with snippets you can use:
1.Create a function that checks the current event name against a given list of event names;
In our scenario, let's assume two things: that we have events we want to require security, and events that we want to require that the person logged in also be an administrator.
<CFFUNCTION name="checkEvent" access="public" returntype="void" output="false">
<CFARGUMENT name="event" type="any">
<CFSET var eventname = arguments.event.getValue(arguments.event.getValue("eventValue")) />
<CFSET var user = arguments.event.getValue("currentUserObject") />
<CFIF not user.getUserID() and not listFindNoCase("login,signup,forgotpassword,sendpassword", eventname)>
<!--- if we aren't logged in AND the event we're calling is NOT a public event... --->
<CFSET arguments.event.addResult("LoginNeeded") />
<cfelse><!--- we are logged in. If this event is in our list of events requiring admin login, check to see our user is an admin. if not, redirect them to home. --->
<cfif listFindNoCase("admin.home,admin.billing,admin.creditAccount", eventname)
and not user.getRole("Admin")>
<CFSET arguments.event.addResult("AdminNeeded") />
</cfif>
</CFIF>
</CFFUNCTION>
<CFARGUMENT name="event" type="any">
<CFSET var eventname = arguments.event.getValue(arguments.event.getValue("eventValue")) />
<CFSET var user = arguments.event.getValue("currentUserObject") />
<CFIF not user.getUserID() and not listFindNoCase("login,signup,forgotpassword,sendpassword", eventname)>
<!--- if we aren't logged in AND the event we're calling is NOT a public event... --->
<CFSET arguments.event.addResult("LoginNeeded") />
<cfelse><!--- we are logged in. If this event is in our list of events requiring admin login, check to see our user is an admin. if not, redirect them to home. --->
<cfif listFindNoCase("admin.home,admin.billing,admin.creditAccount", eventname)
and not user.getRole("Admin")>
<CFSET arguments.event.addResult("AdminNeeded") />
</cfif>
</CFIF>
</CFFUNCTION>
2.Register that function to be called at 'onRequestStart';
<controller name="MyController" type="controller.Controller">
<message-listener message="OnRequestStart" function="checkEvent" />
</controller>
<message-listener message="OnRequestStart" function="checkEvent" />
</controller>
3.In the Modelglue.xml file, create an event called "modelglue.OnRequestStart";
and
4.Within the modelglue.OnRequestStart event, register named results and provide appropriate redirection values;
<event-handler name="modelglue.OnRequestStart">
<results>
<result name="LoginNeeded" do="login" redirect="true" />
<result name="AdminNeeded" do="home" redirect="true" />
</results>
</event-handler>
<results>
<result name="LoginNeeded" do="login" redirect="true" />
<result name="AdminNeeded" do="home" redirect="true" />
</results>
</event-handler>
As with anything Model-Glue or OO, there's always greater levels of detail to be expounded upon, but these snippets are more for illustrative purposes than actual 'out of the box' code, so I'm leaving a lot of the details to you. Such as where you should really store your lists of named events, or how your user object is always present, empty or populated, regardless of whether or not the user is authenticated, etc.
Anyway, hope this helps get somebody over the hump!
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Re: Basic Event Security in Model-Glue Applications
Thanks Doug for writing these concepts in your own words.
Isn't
built into the modelglueapplicationtemplate?
Isn't
built into the modelglueapplicationtemplate?
Posted by Phillip Senn on February 21, 2008 at 8:39 AM
Re: Basic Event Security in Model-Glue Applications
Thanks Doug for writing these concepts in your own words.
Isn't
message-listener message="OnRequestStart" function="OnRequestStart"
built into the modelglueapplicationtemplate?
Isn't
message-listener message="OnRequestStart" function="OnRequestStart"
built into the modelglueapplicationtemplate?
Posted by Phillip Senn on February 21, 2008 at 8:40 AM