Hi Manny & Lee,

 

I wanted to get the changes that we made to the LWM service in front of you so that we can discuss fully once I clear out here. Everything has been published to Azure.

 

Additional fields

Based on our quick discussion on Friday, we added the following items to the AppTrak call to make reporting easier and to fit in more with MB’s needs:

 

1.       mbci – campaignID

2.       mbcn – campaignName

3.       mbpp – publisherProperty

4.       mbpi  - publisherPropertyID

 

This data is stored in separate, normalized tables to make reporting fast and regular. You may continue to use “ecmdx” for storing the data, just be aware that if you want to do that we’ll need to change the analytics.

 

Crypto utility

In order to keep everything nice and secure with regards to redirects and callbacks, there’s a new encryption utility that you can call to create encrypted blobs of information. The encryption is accomplished by symmetric AES key that’s stored on the server, and resides in the Analytics app so that it’s inaccessible from the public. The passphrase for the encryption is set in the web.config, and must match in both the Analytics app and the Metrics app.

 

To create an encrypted value, pass the value to this endpoint:

 

/encrypt?eval=http%3A%2F%2Fwww.mediabrix.com

 

JSON Return:

{"eval":"52DB6945467A9726B66B948E60B93F747E69CA64BF5C7FBF2FA51429BDCAFC19"}

 

It will return back a hex encoded string that can be passed to the metrics server. To test the decryption, pass the encoded value to this endpoint:

/decrypt?eval=52DB6945467A9726B66B948E60B93F747E69CA64BF5C7FBF2FA51429BDCAFC19

 

JSON Return:

{"eval":"http://www.mediabrix.com"}

 

In order to have the metrics service recognize that you’re passing an encrypted value, prepend the value with the string “enc-”.

 

Potential use cases for this are to secure campaign IDs, publisher information, and redirects (see next item).

 

 

 

Redirect

We wired in several different methods to fire a redirect within the AppTrak call. There are two fields:

1.       ered – the URI to push out as the redirect.

2.       etyp – this can be “1”, “2”, “3”, or “7” corresponding to a 301, 302, 303, or 307 status code. This will default to 301.

 

I strongly recommend you encrypt the ered field, not just for tamper resistance but for possible failures on encoding.

 

Those two fields are wired in to the AppTrak service and will fire if populated.

 

As requested, a single call can be made to a new endpoint for both testing & use for performing a redirect. A REST call is included to make the URL smoother.

 

Sample

Encrypt http://www.google.com using the above call returns 603646C9489B4DDCBC3C74D85965609C0585C0C19A4BF7511A6FB3AC6CBB9E3E

 

A call to either of these two endpoints will create a 301 redirect:

 

/r/enc-603646C9489B4DDCBC3C74D85965609C0585C0C19A4BF7511A6FB3AC6CBB9E3E

/redirect?ered=enc-603646C9489B4DDCBC3C74D85965609C0585C0C19A4BF7511A6FB3AC6CBB9E3E

 

A 307 redirect can be called by either of these two:

/r/enc-603646C9489B4DDCBC3C74D85965609C0585C0C19A4BF7511A6FB3AC6CBB9E3E/7

/redirect?ered=enc-603646C9489B4DDCBC3C74D85965609C0585C0C19A4BF7511A6FB3AC6CBB9E3E&etyp=7

 

 

Best,

 

Aaron

 

 

 

 

PS, I was kidding last week – LWM stands for “Light Weight Metrics”. :-)