Basic Introduction

cross-origin access means that the domain in which the resource initiating the request is located is different from the domain in which the resource pointed to by the request is located. For security reasons, browsers will restrict this non-homologous access. However, in practical applications, cross-origin access requests are often encountered. For example, the back end of the user‘s website A (http://domainA.example) uses BOS storage. The user wants to refer to the resources stored on BOS in the website¡¯s Web application, but the page can only initiate requests to the website domain name http://domainA.example, and requests sent to other websites will be restricted by browsers.

Cross-origin Resource Sharing (CORS) is a standard cross-origin solution provided by HTML5, and BOS supports CORS standard for cross-origin access currently. For specific CORS rules, please refer to W3C CORS Specification CORS indicates its source domain through the Header with Origin attached to the HTTP request, such as the above example, where Origin’s Header is http://domainA.example. After receiving this request, the server side will judge whether to allow the request of the source domain according to certain rules. If allowed, the server will attach the Header of Access-Control-Allow-Origin to the returned response, with the content of http://domainA.example to indicate that the cross-origin access is allowed. If the server allows cross-origin requests from any domain name, the Header of Access-Control-Allow-Origin can be set to *. The browser determines whether the cross-origin request is successful according to whether the corresponding Header is returned. If no corresponding Header is attached, the browser will intercept the returned result. If it is not a simple request, the browser will first send an OPTIONS request (pre-request) to detect whether the cross-origin request is safe and acceptable to the server. If the server does not support the following operations, the browser will intercept the cross-origin request.

BOS supports the configuration of CORS rules, please refer to Cross-origin Resource Sharing.

Operation Method

BOS provides developers with two ways to configure cross-origin access rights of bucket resources. One is to directly set CORS rules for bucket in BOS console. The other is to recall CORS-related API interfaces to control access to bucket resources.

• Setting through the console:

  1. Click the "Basic Configuration" tab, select "Cross-origin Access CORS Settings" and click "Modify Configuration".
  2. Click "OK" to save the rule.

• API control method:

  1. PutbucketCors Interface: used to set a cross-origin resource sharing (CORS) rule on the specified bucket, and overwrite the original rule if it exists.
  2. GetbucketCors Interface: to get the current CORS rule for the specified bucket.
  3. DeleteBucketCors Interface: used to turn off the CORS function of the specified bucket and clear all rules.
  4. OPTIONS Object Interface: This interface responds to a cross-origin request when the browser sends a preflight request (OPTIONS) with specific source domain, HTTP method, and Header information to the BOS to decide whether to send a real request.

Note:

• CORS configuration in BOS is at bucket level;
• Whether a CORS request passes or not is completely independent of the BOS authentication, because the CORS rule is only a rule used to determine whether to attach a CORS-related Header, and whether to intercept the request is entirely up to the browser.

Note

• CORS is only meaningful for the browser environment, and the relevant Header attachment is automatically completed by the browser without manual operation by the user.
• CORS request is completely independent of BOS identity verification, that is, CORS rule is only a rule used to decide whether to attach CORS-related Header, and whether to intercept the request is entirely up to the browser.
• When using cross-origin requests, you need to pay attention to whether the browser has the Cache function turned on. When two pages running on the same browser from different domains http://domainA.example and http://domainB.example request the same cross-origin resource at the same time, if the request from http://domainA.example arrives at the server first, the server returns the resource to the user with the Header of Access-Control-Allow-Origin as http://domainA.example. At this time, http://domainB.example initiates another request, and the browser will return the last request result of Cache to the user. At this time, the content of Header does not match the requirements of CORS, which will lead to the failure of the following request.