Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

Cross-Origin Resource Sharing (CORS) is a W3C spec that allows cross-domain communication from the browser. A resource makes a cross-origin HTTP request when it requests a resource from a different domain to its own. For example, an HTML page served from http://domain-a.com makes an <img> src request for http://domain-b.com/image.jpg.

The Cross-Origin Resource Sharing (CORS) mechanism gives web servers cross-domain access controls, which enable secure cross-domain data transfers. The Cross-Origin Resource Sharing standard works by adding new HTTP headers that allow servers to describe the set of origins that are permitted to read that information using a web browser.  Additionally, for HTTP request methods that can cause side-effects on server's data (in particular, for HTTP methods other than GET), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method.

Simple Request

A request that doesn’t trigger a CORS preflight—a so-called “simple request”—is one that meets all the following conditions:

The only allowed methods are:

  • GET
  • HEAD
  • POST

Apart from the headers set automatically by the user agent, the only headers which are allowed to be manually set are:

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (but note the additional requirements below)
  • Last-Event-ID
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width

    The only allowed values for the Content-Type header are:
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

Communication Example

HTTP Request

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

HTTP Response

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

Preflighted Request

Unlike “simple requests”, "preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.

In particular, a request is preflighted if any of the following conditions is true:

If the request uses any of the following methods:

  • PUT
  • DELETE
  • CONNECT
  • OPTIONS
  • TRACE
  • PATCH

Or if, apart from the headers set automatically by the user agent, the request includes any headers other than those which allows the Simple Requests.

Communication Example

HTTP Request

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

HTTP Response

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example/
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

Once the preflight request is complete, the real request is sent:

HTTP Request

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

HTTP Response

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example/
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

How to enable CORS in SAP Netweaver Platform

It is technically possible to configure SAP NetWeaver Application Server to support CORS, so that your web application landscape can be greatly simplified as below:

The trick is simple. Add a rewrite rule for NetWeaver’s ICM component, so that it returns the necessary CORS headers.

First, configure the NetWeaver Application Server’s profile, enable HTTP rewriting and point to the action/rewrite file. In the below example on a Windows installation, the action file is the rewrite.txt file.

icm/HTTP/mod_0 = PREFIX=/,FILE=D:\usr\sap\<SID>\SYS\profile\rewrite.txt

In the action file, maintain the following settings to inject the necessary CORS headers. Make sure you specify your web server’s URL as the value of the Access-Control-Allow-Origin header.

SetResponseHeader Access-Control-Allow-Origin https://<YourWebServerHost>

SetResponseHeader Access-Control-Allow-Credentials true

SetResponseHeader Access-Control-Allow-Methods "GET, POST, PUT, OPTIONS"

SetResponseHeader Access-Control-Allow-Headers "X-Csrf-Token, x-csrf-token, x-sap-cid, Content-Type, Authorization"

SetResponseHeader Access-Control-Expose-Headers x-csrf-token

In a large deployment of SAP NetWeaver landscape, it is often the case that there are multiple server nodes and a load balancer such as SAP Web Dispatcher sits in front of the multiple server nodes. In this case, you can turn on CORS support on the SAP Web Dispatcher instead of on each and every server node. With the Web Dispatcher version 7.49 PL112 or above, it offers more granular support (comparing to NetWeaver’s ICM component) on where the CORS requests come from so that it can act accordingly. Here is an example:

if %{HEADER:ORIGIN} = https://<WebServer1> [OR]

if %{HEADER:ORIGIN} = https://<WebServer2>

  begin

     SetResponseHeader Access-Control-Allow-Origin %{HEADER:ORIGIN}

     SetResponseHeader Access-Control-Allow-Credentials true

     SetResponseHeader Access-Control-Allow-Methods "GET, POST, PUT, OPTIONS"

     SetResponseHeader Access-Control-Allow-Headers "X-Csrf-Token, x-csrf-token, x-sap-cid, Content-Type, Authorization"

     SetResponseHeader Access-Control-Expose-Headers x-csrf-token

  end

  • No labels