All Products
Search
Document Center

:Troubleshooting for OSS cross-origin resource sharing (CORS)

Last Updated:Aug 22, 2022

Issue

To implement cross-domain access and ensure the security of cross-domain Data Transmission Service, Alibaba Cloud Object Storage Service (OSS) reports an error when requesting OSS resources after setting cross-domain resource sharing rules. The error message is as follows:

  • The error returned by the browser is similar to the following.
    OPTIONS http://bucket.oss-cn-beijing.aliyuncs.com/
    XMLHttpRequest cannot load http://bucket.oss-cn-beijing.aliyuncs.com/. 
    Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
    Origin '{yourwebsiet}' is therefore not allowed access. The response had HTTP status code 403.
    Note :CORS errors are usually caused by site applications. You can view the request details in a browser. As in Chrome Browser, press F12 to open the developer tools and view the corresponding elements in the Network.
  • The error returned by OSS is similar to the following.
    <Code>AccessForbidden</Code>
    <Message>
    CORSResponse: This CORS request is not allowed. This is usually because the evalution of Origin,
    request method Access-Control-Request-Method or Access-Control-Requet-Headers are not whitelisted by the resource's CORS spec.
    </Message>
    Note:
    • Errors returned from OSS can be obtained by capturing packets. For example, you can use Wireshark and specify host ([$Bucket_Name].oss-cn-beijing.aliyuncs.com) as the filter to capture packets.
    • Errors returned from OSS can also be obtained by using CORS debugging program oss-h5-upload-js-direct.

Cause

cross-origin resource sharing (Cross Origin Resource Sharing, CORS) may have the following errors:

  • Sources configuration errors
  • Allowed Methods configuration errors
  • Allowed Headers configuration errors
  • Exposed Headers configuration errors

Solution

Check whether the CORS cross-domain rule is set correctly. Perform the following operations:

  1. Log on to the OSS console.
  2. Click Buckets. Click the target bucket to go to the Bucket Overview page.
  3. In the left-side navigation pane, choose Permissions > cross-domain Settings, and then click Settings.
  4. Click Edit in the Actions column corresponding to the rule and perform the following configurations. For more information about how to configure the rule and the precautions, see More information.
    • Set Source to * to confirm that the configuration items is correct. If you set this parameter to *, the upload can be successful. This indicates that the previous source configuration is incorrect. Check carefully based on the rules.
    • Select all the Allowed Methods options, namely, GET, PUT, DELETE, POST, and HEAD, and confirm that the configuration item is correct.
    • Set the Allow Headers parameter to *. If you can call this operation normally, the previous Allowed Headers configuration is incorrect. Check carefully based on the rules.
    • Set Expose Headers to ETag and x-oss-request-id to confirm that the configuration is correct. If you can call this operation normally, the Exposed Headers parameter is incorrectly configured. Check this parameter based on the rules.
  5. If the problem still cannot be solved, see Set cross-domain rules and call OSS still report "No 'Access-Control-Allow-Origin" error.

References

A CORS rule applies only to requests that meet the conditions in the rule. When you configure a CORS rule, do not add multiple sources. When you configure multiple rules, make sure that rules are not in conflict with each other. Only allow the required permissions when you configure other options. To configure a CORS rule, configure the following parameters:

  • Sources: Specify sources whose cross-origin requests are allowed. You can specify multiple sources. You must include complete domain information, such as http://10.X.X.100:8001 or https://www.aliyun.com. Note that do not omit the protocol name HTTP or HTTPS. If the port is not the default 80, you must also include the port. To view information of the domain name, you can use the debugging feature of the browser to view the origin in the header. A domain name supports the * wildcard. A maximum of one * can be used in each domain name, for example, https://*.aliyun.com. If you set Source to *, cross-domain requests from all sources are allowed.
  • Allowed Methods: Select methods based on the request requirements. You can select all methods when you perform debugging.
  • Allowed Headers: Specify allowed headers in a cross-origin request. Separate multiple headers with carriage returns. Each header specified by Access-Control-Request-Headers must match a value in Allowed Headers. Headers are easily missed. If there are no special requirements, we recommend that you set this parameter to *, which indicates that all is allowed and case insensitive.
  • Exposed Headers: the list of headers that are exposed to the browser, that is, the response headers that users access from the application, such as a JavaScript XMLHttpRequest object. No wildcards are allowed. The specific configuration depends on the demands of the application to expose only headers you want to use. If you do not want to expose headers, you can leave this field empty. Exposed headers are case-insensitive.
  • Cache Timeout (Seconds): optional. Specify the time in seconds the browser can cache the response to a preflight (OPTIONS) request to a specific resource. We recommend that you set this parameter to a greater value case-insensitive.
  • Return Vary: Origin: If both CORS and non-CORS requests exist in actual scenarios, or if the Origin header has multiple possible values, we recommend that you configure Vary: Origin to avoid local cache problems.

Related topics

Applicable scope

  • Object Storage Service (OSS)