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 WCS cookies.
The solution to this problem is fairly simple. A servlet filter, the so called cookie leveler, runs in front
of any WCS 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.4.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 IBM, for example via the IBM console.
Now the CAE and the WCS 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 WCS. 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. |