Sub applications should not use session scope directly.

[esprehn]

The below components and files use the session scope directly when they should be using the ModelGlue_APP_KEY to group the sub application session variables to prevent collisions with other sub applications running in the same CF application.

Currently two applications can run into each other with async requests or other state variables in the session in certain load situations.

Affected Files:

ModelGlue.unity.eventrequest.EventContext

ModelFlue.unity.statebuilder.StateBuilder

ModelGlue.unity.framework.ModelGlue

ModelGlue.unity.loader.FrameworkLoader

ModelGlue/unity/ModelGlue.cfm

The files should be using session[ModelGlue_APP_Key] instead of session, which requires some minor changes to the ModelGlue component.

I suggest adding a method to ModelGlue.unity.framework.ModelGlue:

<cffunction name="getSessionScope" access="public" returntype="struct" output="false">
  <cfif len(getApplicationKey())>
    <cfif not structKeyExists(session,getApplicationKey())>
      <cflock scope="session" timeout="10">
        <cfif not structKeyExists(session,getApplicationKey())>
          <cfset session[getApplicationKey()] = structNew()>
        </cfif>
      </cflock>
     </cfif>
    <cfreturn session[getApplicationKey()]>
  </cfif>
  <cfreturn session>
</cffunction>

Then the EventContext and StateBuilder components can use variables._framework.getSessionScope() to access the currently active session and ModelGlue.cfm can use _ModelGlue.framework.getSessionScope(). Of course the ModelGlue component can just use getSessionScope() directly.

The ModelGlue.unity.loader.FrameworkLoader component should also be changed to use the below code instead of generating a random key with CreateUUID(), then adding and deleting it. I doubt very much that there will ever be a collision with the UUID, but using a simple structKeyExists() removes that chance entirely, and also removes 2 function calls and one local variable!

/ModelGlue/unity/loader/FrameworkLoader.cfc:38
<cftry>
	<cfset structKeyExists(session,"test")
	<cfcatch>
		<cfset mg.setUseSession(false) />
	</cfcatch>
</cftry>

I can prepare a patch if you guys want. :)

[esprehn]

Oh, my mistake, that should be session._ModelGlue[ModelGlue?_APP_KEY], and the getSessionScope() function should be changed accordingly.

[esprehn]

session._ModelGlue[ModelGlue_APP_KEY] (doh! wiki formatting.)

[esprehn]

Replying to esprehn:

session._ModelGlue[ModelGlue_APP_KEY] (doh! wiki formatting.)

Here's a complete fix (with the corrected issue in the comments above):

<cffunction name="getSessionScope" access="public" returntype="struct" output="false">

   <cfif not structKeyExists(session,"_ModelGlue")>
      <cflock scope="session" timeout="10">
         <cfif not structKeyExists(session,"_ModelGlue")>
            <cfset session._ModelGlue = structNew()>
         </cfif>
      </cflock>
   </cfif>
   
   <cfif len(getApplicationKey())>
         <cfif not structKeyExists(session._ModelGlue,getApplicationKey())>
            <cflock scope="session" timeout="10">
               <cfif not structKeyExists(session._ModelGlue,getApplicationKey())>
                  <cfset session._ModelGlue[getApplicationKey()] = structNew()>
               </cfif>
            </cflock>
         </cfif>
      
      <cfreturn session._ModelGlue[getApplicationKey()]>
   </cfif>

   <cfreturn session._ModelGlue>
</cffunction>

[boomfish]

The issue still exists in Model-Glue 3, but the code in question has been completely rewritten so none of the patches provided will work.

Suggested fix is to inject the ModelGlue_APP_KEY string into the SessionBasedStatePersister bean and have the bean prefix the _modelgluePreservedState and _modelgluePreservedLog keys with this string when calling the session facade.