The browser sends cookies to a server that runs in the same domain, that is saved with the cookie. In general the cookie domain of a cookie is left empty, so that the browser stores the exact host name of the server that responded to a request. But because the CAE and the commerce system must have different host names (via their virtual host), the CAE would never receive commerce system cookies.

Figure 8.3. Content-led integration scenario

The solution to this problem is fairly simple. A servlet filter, the so called cookie leveler, runs in front of any HCL Commerce storefront call. It wraps the HttpServletResponse into a custom one, that intercepts addCookie() method calls in order to set the cookie domain to a configurable value.

You have to enable the cookie leveler from within your web.xml file of your storefront and preview webapp, which is described in Section 3.5, “Configuring the Cookie Domain”

The cookie leveler should be executed prior to any other filter that may add cookies to the response. In general CoreMedia recommends you to put its filter mapping definition in front of any other filter mapping.

There is one cookie that cannot be customized that way, the JSESSION cookie, which is set by the WebSphere servlet container. You have to configure it via the usual mechanisms provided by HCL, for example via the HCL console.

Now the CAE and the commerce system only need to be put into the same domain, for example helios.blueprint-box.vagrant for the CAE and shop-helios.blueprint-box.vagrant for the HCL Commerce system. The cookie domain must then be configured to be .blueprint-box.vagrant

Note

The cookie domain must not be a top level domain, for example .com, because that would mean, every website in the .com domain will receive the cookies. Because that does not make any sense, cookies with only a top level domain are generally not sent at all.