Powered by Squarespace
Popular Categories
Blog Posts
Discussion Activity
Cisco Live 365
« When the Cloud Evaporates | Main | Google .PROD gTLD rears its head and screams "look at me" »

Magic cookie to toggle backend server farm from prod to stg

Normally, testing against a staging environment takes place with hostnames for that specific purpose and differ from the production hostnames. These hostnames align with different VIPs (Virtual IPs) on a load-balancer to direct the traffic flow to the appropriate backend staging server farm.  This works well when the client can easily and manually switch the hostname between staging and prod. 
Testing mobile apps and third-party sites that may link back to yours poses an issue:  How do you control the hostname linked to you so it hits your staging environment for testing?  Not easily.  On a desktop or laptop, testers happily </sarcasm> modify their local hosts file to get a production hostname to use the VIP (or IP address) for the staging (STG) environment.

Say hello to the magic cookie!

I propose a special cookie that gets toggled into existence from prod to signal that the next request on the same hostname should be diverted by the load-balancer to land on the staging farm.  The toggle could either be a link on a page or a control of your liking.  In honor of Patrick Henry, this cookie is named __GiveMeStagingOrGiveMeDeath.
The toggle works like this:
  1. Check for the existence of the magic cookie.  
  2. When null, we are on prod, so set this cookie to an arbitrary value like movistar or redbull.
  3. When not null, we are on staging, so delete this cookie (by setting expiration in past).
The cookie parameters are:
  • Set session cookie or max-age 86400 secs (1 day)
  • Name: __GiveMeStagingOrGiveMeDeath
  • Value: Movistar (value doesn’t matter)
  • Domain: (allow this cookie to carryover to subdomains)
  • Path: / (or default)
Max-age is a safety-valve in case you’re not using a session cookie and you want to switch back to prod automatically after some reasonable period of time.  This helps a tester frequently restart a browser and still have the magic cookie.
This cookie can be long and arbitrary to avoid name collisions with simple cookie names like staging=true which developers may intend to use for other purposes.  [Thanks to Sko for this suggestion.]
For security concerns landing on staging or when that environment should only be reached from whitelisted source IP addresses, a redirect to the stg hostname could be used.  This obviously adds additional latency to redirect every request intended by the magic cookie to land on STG, but this should be acceptable in most cases given this is being done in a test environment.   The leading dot (.) in the cookie domain is important so the magic cookie shows up on the stg site to facilitate the toggle back to prod.


Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Textile formatting is allowed.