This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

CORS in a SAP Netweaver Landscape

In this brief article I’m going to try to simplify and articulate what Cross-Origin Resource Sharing (CORS) is, how it works and how in an SAP environment (we use Fiori in our example) we can get around CORS without the complexity of rigidly defining the resource associations in the landscape.

Let’s Look At What CORS Is:

Fundamentally CORS is a protection measure introduced in around 2014 inside Web browsers, to try and prevent in-browser content manipulation issues associated with JavaScipt accessing resources from other websites without the knowledge/consent of the Web browser user.

You may be thinking “Why is this a problem?”, well, it’s complex, but a simple example is that you access content on one Web server, which uses JavaScript to access content on another Web server.  You have no control over where the JavaScript is going and what it is doing.
It doesn’t mean the other Web server in our example, is malicious, it could actually be the intended victim of malicious JavaScript being executed in the context of the source Web server.

What Does “Consent” Mean?

There is no actual consent given by the Web browser user (you). You do not get asked.

It is more of an understanding, built into the Web browser which means the Web browser knows where a piece of JavaScript has been downloaded from (its origin), versus where it is trying to access content from (its target), and causes the Web browser to seek consent from the target Web server before allowing the JavaScript to make its resource request to the target.

A simple analogy:
Your parents are the Web browser.
You (the child) are the untrusted JavaScript downloaded from the source Web server.
You want to go and play at your friend’s house (the target Web server).
Your parents contact your friend’s parents to confirm it’s OK.
Your parents obtain consent for you to go and play and the type of play you will be allowed to perform, before they let you go and play at your friend’s house.

Based on the simple analogy, you can see that the Web browser is not verifying the content on the target, neither is it validating the authenticity of the target (apart from the TLS level verification if using HTTPS).
All the Web browser is doing, is recognising that the origin of the JavaScript is different to its target, and requesting consent from the target, before it lets the JavaScript make it’s resource request.

If the target Web server does not allow the request, then the Web browser will reject the JavaScript request and an error is seen in the Web browser JavaScript debugger/console.

What Does “Accessing” Mean?

When we talk about JavaScript accessing resources on the target Web server, we are saying that it is performing an HTTP call (XML HTTP), usually via the AJAX libraries using one of a range of allowed methods. These methods are the usual HTTP methods such as GET, PUT, POST, HEAD etc.

What is the flow of communication between origin Web server, Web browser and target Web server?

Below I have included a diagram that depicts the flow of communication from a user’s Web browser, between a Fiori Front-End Server (FE1) and a Back-End SAP system (BE2).

In the example, pay attention to the fact that the domain (the DNS domain) of the FE1 and BE2 SAP systems, are different.

So, for example the FE1 server could be and the BE2 server could be

1, The user of the Web browser navigates within Fiori to a tile which will load and execute a JavaScript script from FE1.

2, The JavaScript contains a call to obtain (HTTP PUT) a piece of information into the BE2 system via an XML HTTP Request (XHR) call inside the JavaScript.

3, The user’s Web browser detects the JavaScript’s intention and sends a pre-flight HTTP request to the BE2 system, including the details about the origin of the JavaScript and the HTTP method it would like to perform.

4, The BE2 system responds with an “allow” response (if it wishes to allow the JavaScript’s request).

5, The Web browser permits the JavaScript to make its request and it sends it’s HTTP request to BE2.

What Needs to Be Configured in BE2?

For the above situation to work, the BE2 system needs to be configured to permit the required HTTP methods from JavaScript on the origin FE1.

This means that a light level of trust needs to be added to configuration of BE2. This is documented in SAP notes and for NW 7.40 onwards.

Is There a Simpler Way?

An alternative method to configuring Netweaver itself, is to adjust the ICM on the target (BE2) to rewrite the inbound HTTP request to add a generic “origin” request. This means you can have many domains making the access request, without needing to maintain too much configuration at the cost of security.
I’m thinking more about what needs to be done, not just in production, but it in all DEV, TST and PrePRD systems, plus config re-work after system copies.
Not only this, but it would be difficult for your URL rewrite to be accurate, so it may end up being applied to all URL accesses, no matter where they come from.  This will impact performance of the Web Dispatcher.
You could solve the performance issue by using a different front-end IP address (service name) for your Web Dispatcher, which is used specifically for requests from your origin system (FE1).  Another option could be (if it’s your own code being called in BE2) to apply a URL path designation e.g. “/mystuff/therealstuff”, whereby the ICM on BE2 can match based on “/mystuff” and rewrite the URL to be “/therealstuff”.

How About an Even Simpler Way?

A much better way, which solves the CORS problem altogether and removes the need to place config on individual systems, is to front both the origin and the target behind the same Web Dispatcher.

This way, CORS becomes irrelevant as the domain of the Web Dispatcher is seen by the Web browser, as both the origin and the target.

To enable the above configuration, we need to ensure that we align the Web Dispatcher DNS domain to either the origin or the target.
It has to be aligned to whichever system we use the message server to load balance the HTTP call. This is a SAP requirement.

For the other back-end server (behind the Web Dispatcher), we use the EXTSRV option of the Web Dispatcher to allow it to talk to the BE2 system.
This has the capability of supplying multiple servers for HA and load balancing (round-robin).   It also means the DNS domain of that system can be different to that of the Web Dispatcher’s.

Blogger Blog: List Posts By Label

If, like me, you have a blog which is hosted on the Google Blogger platform, you may have realised that there’s a lot of features missing, which you get on other platforms such as WordPress.
I specifically wanted to show a list of blog posts (no content, just the title) that have a specific label.
I wanted to have an index or list of links which a reader could click on and all the posts would be displayed that had that label/category.

Here is how I solved the problem.  You can see the results on the left-hand menu:


In my blog site I have the following setup:

I have the usual main (home) page which I’ve configured to show just one blog post in the “Blog Posts Gadget”, plus I have a “Feed Gadget” for showing the latest blog posts.  This gadget can only show posts ordered by date, and does not allow you to search by label.

On the left-hand side I have a “Link List” gadget which I have manually added links to a separate “Page”, which I created in the “Pages” area inside Blogger which contains just JavaScript:

The navigation works like so:

When a reader clicks on the links that I have manually setup in the Feed Gadget on the left-hand side, they are directed to the All-Blog-Posts.html page (the Page that I’ve created) which executes the JavaScript.
The JavaScript parses the query string (the text that follows the “?” in the URL) and determines the label.
The JavaScript uses the Google Blogger V3 API to retrieve the list of posts from my blog that match the label.

Apart from the need to create the “Page” (which I’ve called “All-Blog-Posts.html” and titled “All Posts”), you will also need to create an API key on the Google API platform, so that you can use the Google Blogger API to parse your blog posts.

You can try the Google Blogger API here:

On the right-hand side of the API page, enter the following information:

BlogId – This is the number identifier of your blog and can be seen in your browser when you click on the “Posts” link in Blogger:

FetchBodies – False – we don’t want these.
FetchImages – False – we don’t want these.

Labels – This is a comma seperated list of the labels which are to be found in the posts (this is an ALL INCLUSIVE list and not and OR list) :

Show Standard Parameters – Click this to expand the list:

Fields – Enter “items(title,url)” to return only the URL and Title of matching blog post items:

Authentication – Select OAuth 2.0 and log in using your Google Account in order to test the API:

Click Execute:

The results will be displayed below the execute button in JSON format:

If you do not get a green “200” response, then you should check your entries again.

Before we can create a blog page that uses the API, we need to create an API Key.
Since it costs Google each time someone uses an API, they restrict the API usages with quotas which can be increased (if you want to pay).  For use by the average blog site, the quotas should be sufficient.

You obtain an API key by clicking the “Get A Key” button located on the site here:

Create a new project and click Next:

You’ll get an API key straight away (make a note of it), but you should secure the key against your specific blog domain name, to prevent abuse by others.
To do this, click the “API Console” link just below your provided key (opr go to  and select your Key):

Select the option “HTTP referrers (websites)“, then add as many domain names as you need for your blog (where the API could potentially be called from):

Now you’re ready to create a new static page in your blog which will hold the required JavaScript to call the blogger API and display the blog posts matching the labels.

In your blogger admin site, create a new static page:

Click “New page“:

Give the page a title (e.g. All Posts by Label):

Paste in the JavaScript:

<html xmlns=””>
<title>List All Posts</title>
<script src=””></script>
<script type=”text/javascript”>
var myLabel = allposts_get_qs(“label”);
var myPage = allposts_get_qs(“page”);

document.write (‘<h3>For Label: ‘, myLabel, ‘</h3>’);

function escapeHtml(unsafe) {
return unsafe
.replace(/%2C/g, “,”)
.replace(/&/g, “&”)
.replace(/</g, “<“)
.replace(/>/g, “>”)
.replace(/”/g, “””)
.replace(/’/g, “‘”);

function allposts_get_qs(key) {
var myval=’NoValueSpecified’;
var regex = new RegExp(“[\?&]”+key+”=([^&#]*)”);
var qs = regex.exec(;
if(qs != null) myval = qs[1];
return escapeHtml(myval);

function start() {
var apiKey=’YOUR API KEY‘;
gapi.client.init({‘apiKey’: apiKey,}).then(function() {
return gapi.client.request({‘path’: ‘’+location.origin+’&fields=id’,})
}).then(function(response) {
var theBlogID = JSON.parse(response.body).id;
gapi.client.init({‘apiKey’: apiKey,}).then(function() {
var nPage=”;
if (myPage != ‘NoValueSpecified’) { nPage=’&pageToken=’+myPage }
return gapi.client.request({
‘path’: ‘’+theBlogID+’/posts?labels=’+myLabel+nPage+’&fetchBodies=false&orderBy=updated&fields=nextPageToken%2Citems(title%2Curl)&prettyPrint=false&maxResults=99’,
}).then(function(response) {

var postJSON = JSON.parse(response.body);
var pageToken = postJSON.nextPageToken;

// Grab the container we will put the results into
var container = document.getElementById(“content”);
container.innerHTML = ”;

var html = ‘<ul>’;
var postCount=0;

if ( postJSON.items != null) {
for (var i = 0; i < postJSON.items.length; i++) {
var post = postJSON.items[i];
html += ‘<li><a href=”‘ + post.url + ‘” target=”_top”>’ + post.title + ‘</a></li>’;

html += ‘</ul><br/>’+postCount+’ matching posts displayed.’ ;

if (pageToken != null) {
html += ‘<br/><br/><a href=”‘ + location.origin + location.pathname + ‘?label=’+myLabel+’&page=’ + pageToken+ ‘”>Next Page >’;

container.innerHTML = html;

}, function(reason) { console.log(‘Error: ‘ + reason.result.error.message); });
}, function(reason) { console.log(‘Error: ‘ + reason.result.error.message); });

if ( allposts_get_qs() != null ) { gapi.load(‘client’, start) };

<body style=”border: 0 none; font-family: Arial;”>
<div id=”content” style=”width: 100%;”>Loading…</div>

You should replace: YOUR API KEY   with your new API key you generated earlier.

Publish your new static page on your blog (you will not see it, but you can reference it):

Now it’s visible to the internet, you can test your new static page by opening it in your web browser.
From within the Blogger admin console, click “View” for the new page:

Change the URL in your browser to add the parameter for the label you want to filter by:

Example:   < Adding “?label=abc”
Gives the following URL:

You should see:

If you put a valid label (one that you have used) then you should see those blog posts listed.
NOTE: The label filter is case sensitive.  This is an API feature.  You will need to ensure that all your posts have the correct/same case for the filter to show them.

TIP: To add spaces in a label you need to URL Encode the label using “%20” instead of the space.

That’s it!
You can now decide how you wish to present the filter.  E.g. in my case I’ve used the “Linked List” gadget and I manually add them.  But you could do something else if you wish.