[coldbox 3.5.3] rc in configure function of RequestContextDecorator is empty struct

Hi guys,

As far as I know this used to work perfectly, but it does not anymore as was discovered during a penetration test of our websites…


writedump(rc, "E:\www\development\ContextDecorator\mydump.html");

// Clean the entire request collection
var antiSami = getController().getPlugin(“AntiSamy”);
for(key in rc)
{
if(isSimpleValue(rc[key]))
{
rc[key] = antiSami.HtmlSanitizer(rc[key]);
}
}

In any request, the dump of RC is an empty struct. According to the docs RC should have been populated when configure is run:

configure() A pseudo-constructor method that get’s executed right after a request has been captured

I used a new empty coldbox 3.5.3 app on Coldfusion 10; All i added is the decorator as shown here and requestContextDecorator = “model.DefaultRequestContext” in the Coldbox.cfc config.

New bug?

Tom that should be the expected behavior. Maybe you can investigate.

Luis Majano
CEO
Ortus Solutions, Corp
Toll Free/Fax: 1-888-557-8057
Direct: 909-248-3408
www.ortussolutions.com
Twitter: @lmajano, @ortussolutions

Hi Luis,

Something most definitely changed.

The following example from http://wiki.coldbox.org/wiki/Recipes:My_First_Request_Context_Decorator.cfm

 **<cffunction** name="Configure" access="public" returntype="void" hint="This is the configuration method for your context as its created." output="false" >
	**<cfset** var key = "">
	<---  Get the original collection via the original request context object and call a non-decorated method --->
	**<cfset** var rc = getRequestContext().getCollection()>
	
	<---  I will trim all of the request collection --->
	**<cfloop** collection="#rc#" item="key">
			
		<---  Trim only simple values --->
		**<cfif** isSimpleValue(rc[key])>
			**<cfset** rc[key] = trim(rc[key])>
		**</cfif>**
			
	**</cfloop>**
**</cffunction>**

Seams it was caused during fix fixed #1259 enhanced request context decorator delayed configuration

https://github.com/ColdBox/coldbox-platform/commit/d0f35a65d83a6b57c89860f6b09e82f06b9128be

But there is no delayed configuration. You can pre-populate your RC using this configure method, but there is no way you can do post populate checks.

Cheers,
Tom

I thought the configure method was run when the component was created, which means if this is true during the setup of the application then there will be no RC.

If you do wish to sanitize the RC then the best option would be on the preRequest, preProcess or similar events.

That is what we did, but Luis suggested to do it in decorator instead…

The entire http://wiki.coldbox.org/wiki/Recipes:My_First_Request_Context_Decorator.cfm is dedicated to this behaviour. But it does not work as expected.

We moved back to Main.preRequest for now.

Cheers,
Tom

Yeah there is probably a good reason for that suggestion, I haven’t worked with the decorators for awhile and I personally never thought about doing it there, and opted for the other events all the time.

Maybe a revisit into these may help understand, but I am guessing that the decorator is a singleton which would explain the behavior your seeing.

Nah it has nothing to do with that, the configure is just called at the wrong moment, Luis asked me to investigate.

Cheers,
Tom

ok, fair enough I was guessing.

I have to admit…

The statement

configure() A pseudo-constructor method that get’s executed right after a request has been captured

Is strange, at best it is a very poor choice of method name. Rather indeed keep it for configuration at creation as Andrew suggests.

A good fix would be to:

  1. add an empty postProcess() method to the coldbox.system.web.context.RequestContext
  2. so that a postProcess() method in coldbox.system.web.context.RequestContextDecorator can act as an override
  3. at the end of the requestCapture() method in coldbox.system.web.context.RequestContext (line 149) add: context.postProcess()

This will work as the none decorated RequestContext will simply do nothing.

Luis, shall I create a pull request for this or do you rather want to keep the behaviour in the old configure() method, so we don’t need to change the current docs?

Cheers,
Tom

I have had a quick look at the code of ColdBox, and I am going to ask how do you know it is not working?

Let me explain a bit further, the configure() is called when the context exists however I am still trying to find out more.

Rather than write a dump file, try adding a logging so that you can see its history as well. It might be that on each request it is being called a number of times where the last time it is actually empty.

Just a thought…

I might have a play as well and see what I can see.

Also what are you running this on ColdFusion 8/9/10 or Railo?

I used a new empty coldbox 3.5.3 app on Coldfusion 10;

And it is empty on the first and any subsequent requests.

However, you will find that requestCapture is only called once in every request, so there would be no subsequent requests.

I have traced the entire flow from bootstrap.

Cheers,
Tom

And configure is called when the context is created, not when it exists.

Yeah that is what I meant to say.

Ok the actual capture happens after it the configure is called, the fact that the configure is called when it is created is as I stated above, but it is called on every request and recreated and built which I think one would expect to happen.

But the RC / PRC is setup later well after the configure is actually run. Which is the why this is happening, well at least that what appears to be happening.

Thanks Andrew,

That is exactly what I said earlier, but that is not the behavior that has been documented, hence the need for a fix, which I already created and is in pull request with Luis.

Cheers,
Tom

Yeah I know I am just helping you confirm what I have found.

Cool thanks.