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 7.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.

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.docker.localhost for the CAE and shop-helios.docker.localhost for the HCL Commerce system. The cookie domain must then be configured to be .docker.localhost

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.