Editing Whitelists and No-Log Lists (CORS)

Modify HTTP whitelists and no-log lists for the context type CORS.

Context

Cross-origin resource sharing (CORS) is a concept for managing queries sent to a server from a domain other than the domain of the web page that originally sent the query. CORS defines the way a web page interacts with the server to determine whether cross-origin queries are permitted or not.

CORS queries can be sent in two different ways:

CORS as simple query

A simple query uses the methods GET, HEAD, or POST. It contains the header Origin, which specifies the original domain of the query, for example http://example.com. As a response, the server sends an Access Control Allow Origin header.
CORS as Preflight query
A Preflight query, on the other hand, uses the method OPTIONS and an Origin header to send an HTTP call first. This checks whether the query in question can be sent securely.
```
OPTIONS /
Host: destination.com
Origin: http://example.com
```
The server always responds with an Access Control Allow Origin header and also specifies which methods are permitted (if defined).
```
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: GET, HEAD
```

Only the following response headers are generally accessible in a CORS query:

Cache Control	Content Type	Last Modified
Content Language	Expires	Pragma

If the server wants to give the client access to further headers, it must use the Exposed Headers option.

Prerequisites

To be able to use this function, CORS Support must be activated in your ABAP system.

CORS is deactivated in the system when it is delivered. To activate CORS, go to transaction RZ11 and set th system parameter icf/cors_enabled to 1 (the default is 0).

Procedure

To modify HTTP whitelists and no-log lists for the context type CORS, execute the following steps:

In the UCON HTTP whitelist tool (transaction UCONCOCKPIT HTTP Whitelist Scenario), choose the context type Cross-Origin Resource Sharing (Select Context Type Execute Selection or double click the context type).
In the Logged HTTP Whitelist Checks screen area, choose To Whitelist for a selected log entry to add a corresponding URL pattern to the whitelist. A dialog box appears containing the data of the selected service path and the associated original host name.

Note

You can specify a range of host names using “*” and you can specify multiple host names separated by commas. If you specify a higher level service path (such as sap/bc/), the configuration also applies to all lower level service paths (such as sap/bc/echo/). If you create a whitelist entry with a different configuration for sap/bc/echo, the settings of this entry apply and not the settings of the higher level entry (sap/bc/).

In the <Allowed Methods> section, select methods to specify for which HTTP methods the pattern is valid. The following methods can be selected:

CONNECT	HEAD	POST
DELETE	OPTIONS	PUT
GET	PATCH	TRACE

In the <Allowed Headers> fields, specify whether further headers are allowed in a query. If they are, enter them separated by commas.

Note

This field is mandatory whenever a query contains Access Control Request headers.
In the <Optional Response Header> frame, you can specify whether additional <exposed headers> are made accessible (separated by commas) and (in the case of Preflight queries) whether user logon data is allowed (<Allow Credentials>). For Preflight queries, you can also specify the maximum number of seconds (<Max. Age>) in which the response can be cached (the default is 60).

Note

The <Namespace> field is relevant only if the ABAP system is managed in a cloud environment.

Note

Only one entry is possible for each service path. If a new entry is added to an existing entry for a service path, the two entries are merged. The merged entry contains the total of all settings (for example all allowed methods, host names, and headers) of the original entries plus the last value entered for <Max. Age> and <Allow Credentials>.
Confirm your entries by choosing ENTER. The entry you added appears in the Whitelist area on the top right of the screen.

Note

When you choose Refresh Coverage, select the added log entry in the Logged HTTP Whitelist Checks list, and choose the Details icon, the details of the whitelist entry are display in the Details window. However, the log entry is only displayed if you have already selected the option All or Covered by Whitelist (Allowed) under <Selection>
Repeat the steps above to add a log entry to the no-log list by choosing To No-Log List.
The entry you added appears in the No-Log List area on the bottom right of the screen.

Note

You should only add patterns for URLs to the list if you are sure that they are not meant to be covered by the whitelist (for example, if a particular domain or host is always to be blocked). URLs that are covered by the no-log list are only displayed under Logged HTTP Whitelist Checks if you have chosen All under <Selection>. If you choose Refresh Coverage, you can see in the Covered by column whether the log entry is covered by a whitelist entry (green traffic light) or no-log list entry (yellow traffic light) or whether it has not yet been captured by a pattern (red traffic light).
You can add entries manually as well as edit or delete existing entries in both the whitelist and the no-log list.
Choose Save to activate changes to the whitelist or no-log list.