Offered By: IBM
Enabling Cross-Origin Resource Sharing (CORS) in a RESTful Java microservice
Learn how to enable Cross-Origin Resource Sharing (CORS) in Open Liberty without writing Java code.
Continue readingGuided Project
Open Liberty
53 Enrolled4.8
At a Glance
Learn how to enable Cross-Origin Resource Sharing (CORS) in Open Liberty without writing Java code.
You will learn how to add two server configurations to enable CORS. Next, you will write and run tests to validate that the CORS configurations work. These tests send two different CORS requests to a REST service that has two different endpoints.
CORS and its purpose
Cross-Origin Resource Sharing (CORS) is a W3C specification and mechanism that you can use to request restricted resources from a domain outside the current domain. In other words, CORS is a technique for consuming an API served from an origin different than yours.
CORS is useful for requesting different kinds of data from websites that aren’t your own. These types of data might include images, videos, scripts, stylesheets, iFrames, or web fonts.
However, you cannot request resources from another website domain without proper permission. In JavaScript, cross-origin requests with an XMLHttpRequest API and Ajax cannot happen unless CORS is enabled on the server that receives the request. Otherwise, same-origin security policy prevents the requests. For example, a web page that is served from the http://aboutcors.com server sends a request to get data to the http://openliberty.io server. Because of security concerns, browsers block the server response unless the server adds HTTP response headers to allow the web page to consume the data.
Different ports and different protocols also trigger CORS. For example, the http://abc.xyz:1234 domain is considered to be different from the https://abc.xyz:4321 domain.
Open Liberty has built-in support for CORS that gives you an easy and powerful way to configure the runtime to handle CORS requests without the need to write Java code.
Types of CORS requests
Familiarize yourself with two kinds of CORS requests to understand the attributes that you will add in the two CORS configurations.
Simple CORS request
According to the CORS specification, an HTTP request is a simple CORS request if the request method is GET, HEAD, or POST. The header fields are any one of the Accept, Accept-Language, Content-Language, or Content-Type headers. The Content-Type header has a value of application/x-www-form-urlencoded, multipart/form-data, or text/plain.
When clients, such as browsers, send simple CORS requests to servers on different domains, the clients include an Origin header with the client host name as the value. If the server allows the origin, the server includes an Access-Control-Allow-Origin header with a list of allowed origins or an asterisk (*) in the response back to the client. The asterisk indicates that all origins are allowed to access the endpoint on the server.
Preflight CORS request
A CORS request is not a simple CORS request if a client first sends a preflight CORS request before it sends the actual request. For example, the client sends a preflight request before it sends a DELETE HTTP request. To determine whether the request is safe to send, the client sends a preflight request, which is an OPTIONS HTTP request, to gather more information about the server. This preflight request has the Origin header and other headers to indicate the HTTP method and headers of the actual request to be sent after the preflight request.
Once the server receives the preflight request, if the origin is allowed, the server responds with headers that indicate the HTTP methods and headers that are allowed in the actual requests. The response might include more CORS-related headers.
Next, the client sends the actual request, and the server responds.
Created byÂ
The Open Liberty Project team