Cookie Domain Mapping

Performance testing often happens on non-production systems, like a QA or dedicated “perf” environments. In some cases it is easier to directly access those systems for testing instead through a load balancer serving traffic under a shared domain. This approach leads to a typical problem though: Cookie domain mismatches and lost sessions.

Let’s say you are running an e-commerce site and have a QA environment under shop.qa.example.com. The shopping cart is managed by dedicated service running under cart.qa.example.com. In production the entire shop, including the cart component, is served from the same domain under https://example.com. Requests to /cart/* are routed to the shopping cart, while the rest is routed to the shop system.

In production, when everything is served under the same domain, you don’t have any problems. For performance testing there can be any numbers of reasons to directly test against upstream systems. There is usually one problem though: Cookies. The standard cookie rules will not send cookies set for one system to another if the domain does not match.¹

For this reason, we recently added a small feature called “Cookie Domain Mapping”. Cookie Domain Mapping allows to change the rules how cookies are handled in a StormForge test by providing mapping configuration for the domain property of cookies.

How can we apply this to our e-commerce example we’ve already described? The goal is, that cookies set by either system {shop,cart}.qa.example.com have to be available to every other system. To achieve this, you can provide a mapping like this:

session.setOption("cookie_domain_map", {
  "cart.qa.example.com": "shop.qa.example.com",
});

Cookies set by {shop,cart}.qa.example.com will be handled like as if they were set by shop.qa.example.com (storing cookies). The same happens for the decision logic if cookies should be send back to the server (reading cookies). Note that cookies won’t be sent to other domains, like static.qa.example.com.

Example

To get a more complete picture, let’s take a look at a simple user journey with three steps: Visit start page, view a product and add a product to the shopping cart.

Visit start page: A new client visits the start page. In the background a session cookie is generated and returned with a Set-Cookie header:

session.get("http://shop.qa.example.com/");

Nothing special happens here in terms of cookie handling.

View a product: The client now visits a product page. The value from the session cookie is for example used to fill the “recently viewed articles” list.

There is also no special treatment required for this, as the start page was served from the same domain and cookie handling works automatically in those cases:

session.get("http://shop.qa.example.com/4711");

Add product to shopping cart: Now we want to add the item to the shopping cart by performing a POST request. The session cookie is required to internally associate the cart to the correct user. But the domains do not match. We have to configure a domain map to send the cookie regardless of the mismatch:

session.setOption("cookie_domain_map", {
  "cart.qa.example.com": "shop.qa.example.com",
});

session.post("http://cart.qa.example.com/add", { payload: "ean=4711" });

🎉

Conclusion

Cookie Domain Mapping is a simple feature to manipulate the handling of cookies being saved and looked up by simulated clients in a StormForge test. It allows to make Cookies seamlessly work across different domain names which can become handy when testing non-production environments.

Check out our documentation on “Cookie Domain Mapping” to learn more.