Setting Cross-Origin Resource Sharing (CORS)

Overview

Cross-origin access refers to a scenario where the domain of the resource initiating a request is different from the domain of the resource targeted by the request. For security reasons, browsers restrict such non-same-origin access. In practical applications, cross-origin access requests are frequently encountered. For example, if the backend of a user’s Website A (http://domainA.example) uses BOS storage, the user may want to reference resources stored in BOS in the website’s web application. However, the page can only initiate requests to the website domain http://domainA.example; any requests sent to other websites will be restricted by the browser.

Cross-origin resource sharing (CORS for short) is a standard cross-origin solution provided by HTML5. BOS currently supports the CORS standard to achieve cross-origin access. For specific CORS rules, please refer to W3C CORS Specification. CORS indicates its source domain by attaching an Origin header to the HTTP request. Taking the above example, the Origin header would be http://domainA.example. After receiving the request, the server will determine whether to allow the request from this source domain based on specific rules. If allowed, the server will attach an Access-Control-Allow-Origin header to the returned response, with the value http://domainA.example, indicating that this cross-origin access is permitted. If the server allows cross-domain requests from any domain name, set the Access-Control-Allow-Origin Header to *. The browser determines whether the cross-domain request is successful based on whether the corresponding Header is returned. If the corresponding Header is not attached, the browser will intercept the return result. For not-so-simple requests, the browser will first send an OPTIONS request (preflight request) to check if the cross-origin request is secure and acceptable to the server. If the server does not support the subsequent operation, the browser will block the cross-origin request.

Operation types

BOS gives developers two ways to set cross-origin access permissions for bucket resources: directly configuring CORS rules in the BOS console or using CORS-related APIs to manage bucket resource access permissions.

• To configure cross-origin access permissions for bucket resources via the console, please refer to Configuring Cross-Origin Access.

• Configuring cross-origin access permissions for bucket resources via API:

  • PutBucketCors: Used to set a Cross-Origin Resource Sharing (CORS) rule on the specified bucket, overwriting the original rule if it exists.
  • GetBucketCors: Used to obtain the current CORS rules of the specified bucket.
  • DeleteBucketCors: Designed to disable the specified Bucket CORS function and clear all rules.
  • OPTIONS object: Before sending a cross-domain request, the browser will send a preflight request (OPTIONS) with specific origin domains, HTTP methods and Header information to BOS, thus determining whether to send the actual request. This API responds to such requests.

Note:

• CORS configuration in BOS is at the bucket level;
• Whether a CORS request is allowed is entirely independent of BOS’s identity authentication. CORS rules only define whether to attach CORS-related headers, with the browser deciding request interception.

Note

• CORS is only applicable in browser environments. The browser automatically applies the relevant headers, so no manual user input is needed.
• CORS requests are completely separate from BOS’s identity authentication. CORS rules only serve to decide whether to include CORS-related headers, with the browser solely responsible for determining whether to intercept the request.
• When using cross-origin requests, you need to pay attention to whether the browser has enabled the Cache function. When two pages running on the same browser, originating from different domains http://domainA.example and http://domainB.example, simultaneously request the same cross-origin resource, if the request from http://domainA.example arrives at the server first, the server will return the resource to the user with the Access-Control-Allow-Origin Header set to http://domainA.example. At this time, if http://domainB.example initiates a request, the browser will return the cached result of the previous request to the user. At this point, the content of the Header does not match the requirements of CORS, which will cause subsequent requests to fail.