In this chapter, we have used JavaScript to drive a request into Quarkus' service. In a more complex scenario where your JavaScript code is deployed in its own service on a distinct host or context, you will have to implement Cross-Origin Resource Sharing (CORS) to make it work. In a nutshell, CORS allows web clients to make HTTP requests to servers hosted on different origins. By origin, we mean a combination of the URI scheme, hostname, and port number.

This is especially challenging for client-side languages such as JavaScript because all modern browsers require a same-origin policy for scripting languages.

To make this work, we need to put our server applications in charge of deciding who can make requests and what type of requests are allowed in using HTTP headers. In practice, when the server receives a request from a different origin, it can reply and state which clients are allowed to access the API, which HTTP methods or headers are allowed, and finally whether cookies are allowed in the request.

How does that translate into Quarkus configurations? As you may have guessed, the configuration has to be applied to the application.properties file, under the quarkus.http.cors namespace. The following is a sample configuration that allows CORS for all domains, all HTTP methods, and all common headers:

quarkus.http.cors=true
quarkus.http.cors.origins=*
quarkus.http.cors.methods=GET,PUT,POST,DELETE, OPTIONS
quarkus.http.cors.headers=X-Custom,accept, authorization, content-type, x-requested-with
quarkus.http.cors.exposed-headers=Content-Disposition

In real-world scenarios, you would probably set the list of allowed origins to the domain asking to connect remotely, as follows:

quarkus.http.cors.origins=http://custom.origin.com

Now that we've clarified this, we can look at another example where we'll use a Java Enterprise component, such as WebSocket, to reach our Quarkus service.