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.
What Does “Consent” Mean?
There is no actual consent given by the Web browser user (you). You do not get asked.
A simple analogy:
Your parents are the Web browser.
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).
What Does “Accessing” Mean?
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 fe1.group.corp.net and the BE2 server could be be2.sub.corp.net.
What Needs to Be Configured in BE2?
This means that a light level of trust needs to be added to configuration of BE2. This is documented in SAP notes and help.sap.com 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.
You may also be interested in: