[Testbox 2.1.0] Passing HTTP Headers in integration tests

Hi all,

I’m trying to write an integration test for some of my handlers. I have an interceptor set up that checks to make sure that an Authorization key is passed into the header of the request and if it’s not then I return a status code and statusMessage letting the user know that they can not access the event without passing in the proper header.

When I try to run my tests, this fails because I’m not really sure how to get the header passed in when the execute() method runs the event I’m testing.

I thought maybe mocking the http header would work, but I’m either not setting it up correctly or this is not the correct approach.

Can someone provide an example of passing in a header when executing the event. Or maybe tell me the correct way to do this?

Thank you,

Ben

Ben,

How are you mocking the header and how are you retrieving the header?

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
ContentBox Platform: http://www.gocontentbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox

Hi Luis,

I’ve tried a couple of different ways based off of what’s in http://wiki.coldbox.org/wiki/Recipes%3ABasic_HTTP_Authentication/wiki/MockBox.cfm

The API I’m building expects a key/value pair of “Authorization”: “basic 123456” where the 123456 is a Hashed value. I’m just not sure how best to make that work in my test.

I’ve tried a couple of variations like the following, but I’m just totally guessing since Mocking is something I’ve never done before and still trying to fully understand it(which I don’t). So please excuse how badly off I may be on how to do this:

it( “should return a version number”, function(){

var mockEvent = getMockRequestContext();

mockEvent.$(“getHTTPHeader”).$args(“Authorization”).$results("").$(“setHTTPHeader”);

var event = execute( event=“version.index”, renderResults=true );

expect( event.getRenderData().data ).toHaveKey( “message” );
expect( event.getRenderData().data[ “message” ] ).toBe( “Version 2.0.0” );

});

I’ve also tried doing something with getMockBox().prepareMock( getRequestContext() ).$(“setHTTPHeader”) but with no luck and have also tried using cfheader as well.

Any wisdom on how best to accomplish this would be greatly appreciated.

Thanks,

Ben

Hi Luis,

I’ve tried a couple of different ways based off of what’s in http://wiki.coldbox.org/wiki/Recipes%3ABasic_HTTP_Authentication/wiki/MockBox.cfm

The API I’m building expects a key/value pair of “Authorization”: “basic 123456” where the 123456 is a Hashed value. I’m just not sure how best to make that work in my test.

I’ve tried a couple of variations like the following, but I’m just totally guessing since Mocking is something I’ve never done before and still trying to fully understand it(which I don’t). So please excuse how badly off I may be on how to do this:

it( “should return a version number”, function(){

var mockEvent = getMockRequestContext();

The line above gives you a mock request context, not the actual running context. You must prepare the actual context:
prepareMock( getRequestContext() )

mockEvent.$(“getHTTPHeader”).$args(“Authorization”).$results("").$(“setHTTPHeader”);

var event = execute( event=“version.index”, renderResults=true );

expect( event.getRenderData().data ).toHaveKey( “message” );
expect( event.getRenderData().data[ “message” ] ).toBe( “Version 2.0.0” );

});

I’ve also tried doing something with getMockBox().prepareMock( getRequestContext() ).$(“setHTTPHeader”) but with no luck and have also tried using cfheader as well.

Any wisdom on how best to accomplish this would be greatly appreciated.

Now, how are you retrieving the headers in your interceptor?

Okay, so it looks like my second example was a bit closer to at least mocking the HTTP Header?

In the interceptor I’m just using getHttpRequestData().headers and checking for the existence of “Authorization”.

if ( structKeyExists( getHttpRequestData().headers, “Authorization” ) ) {}

That’s your problem right there. You are retrieving it directly via a CF function which can’t be mocked.

You need to retrieve it the way you mocked it via event.getHTTPHeader()

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
ContentBox Platform: http://www.gocontentbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox

Ahhhh, you know as soon as I posted how I was retrieving the header in my interceptor I started to wonder if maybe I shouldn’t be using getHttpRequestData() since I had seen in a couple of examples you use getHTTPHeader().

Thank you for the clarification on that.

Luis(or anyone else who might be able to answer),

I have one follow up question. Mocking the header is working great now but one thing I’m not sure of is the best way for me to get a user to test against to make sure my test passes.

When this interceptor fires it looks at the Authorization header which has an encrypted value which comes through like “Authorization basic abc233444==” If the interceptor finds a valid Authorization header it then decrypts the value which is an apikey and does a look up in the database to make sure it’s valid key.

My question is, before I mock the authorization header should I create a new dummy user in the database and encrypt the values to pass into the mocked header so that when the query look up runs it finds a valid user and the test passes. Once the test passes or fails, then remove that user? I don’t think I can mock a user in this case since I’m executing an event that has to get past the interceptor before it will execute.

I don’t want to rely what’s currently in the database, because I have no way of knowing if that user will actually exist in the future or if our testing environment will even have that user. What I have done on another app where I was just starting to use testbox was create a clone of the database and prefix it with test_ and have all the tables empty so I can write data as needed. I also recently came across a blog post somewhere where they were setting up the ORM settings in the Application.cfc of the tests directory to dropcreate and passing in a sql script for creating tables and seeding data which was pretty cool.