close

Filter

loading table of contents...

Connector for SAP Commerce Cloud Manual / Version 2301

Table Of Contents

5.4 Solutions for the Same-Origin Policy Problem

When the commerce system has to deliver the end user's web pages, CoreMedia Content Cloud offers a way to enrich those web pages with content from the CoreMedia CMS; the fragment connector.

Integrating content from the CoreMedia system into the shop pages presents a challenge due to the same-origin policy:

Cross Domain Scripting with Fragments

Figure 5.6. Cross Domain Scripting with Fragments


The image above shows a typical situation when a user requests a shop page that includes CoreMedia fragments.

  1. The page request from the end user is sent to the commerce server.

  2. While rendering the page, the commerce server requests a fragment from the CAE.

  3. The returned fragment contains itself parts that must be delivered dynamically. Take the login button. It is user specific, hence it must not be cached. The CoreMedia Blueprint may include such parts via Ajax requests or as ESI tags, depending on the capabilities of the component which sent the request.

  4. The commerce server returns the complete page, including the fragment that was rendered by the CAE.

  5. Because it is assumed that the CoreMedia eCommerce fragment contains a dynamic part, which must not be cached, the browser tries to trigger an Ajax request to the CAE. But this breaks the same-origin policy and will not succeed.

Solution 1: Access-Control-Allow-Origin

The first solution is built into the CoreMedia Blueprint workspace, so you may use it out of the box. The idea is to customize the same origin policy by setting the Access-Control-Allow-Origin HTTP header accordingly. The allowed origins can be configured via the properties cae.cors.allowed-origins-for-url-pattern[*].

cae.cors.allowed-origins-for-url-pattern[{path\:.*}]= \
    http://my.site.domain1,https://my.site.domain2

To fine-tune the configuration for Cross-Origin Resource Sharing (CORS), use the provided cae.cors configuration properties. See Section 3.1.4, “CORS Properties” in Deployment Manual and Section 4.3.1.8, “Solution for the Same-Origin Policy Problem” in Content Application Developer Manual.

Solution 2: The Proxy

To solve this problem the classical way, the Ajax request needs to be sent to the same origin than the whole page request in step 1 was. The next image shows the solution to this problem: A reverse proxy needs to be put in front of both the CAE and the commerce server.

Cross Site Scripting with fragments

Figure 5.7. Cross Site Scripting with fragments


Actually, you may use any proxy you feel comfortable with. The following snippet shows the configuration for a Varnish. Two back ends were defined, one for the CoreMedia eCommerce CAE named blueprint and another one for the commerce server named commerce.

The vcl_recv subroutine is called for every request that reaches the Varnish instance. Inside of it the request object req is examined that represents the current request. If its url property starts with /blueprint/, it will be sent to the CoreMedia eCommerce CAE. Any other request will be sent to the commerce system. (~ means "contains" and the argument is a regular expression)

Now, if you request a shop URL through Varnish and the resulting page contains a CoreMedia eCommerce fragment including a dynamic part that must not be cached, like the sign in button, the Ajax request will work as expected.

backend commerce {
    .host = "ham-its0484-v";
    .port = "80";
}

backend blueprint {
    .host = "ham-its0484";
    .port = "40081";
}

sub vcl_recv {
    if (req.url ~ "^/blueprint/") {
      set req.backend = blueprint;
    } else {
      set req.backend = commerce;
    }
}

Search Results

Table Of Contents
warning

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.