OSS access

Last Updated: Mar 29, 2017

OSS access URLs

OSS is an object storage service based on HTTP APIs. For all operations, users need to specify the OSS resource to access. This resource may be a bucket or an object. During OSS access, the OSS resource is expressed as a URL that indicates third-level domain name access, which is formatted as follows:

  1. <Schema>://<Bucket>.<Endpoint>/<Object> Third-level domain name access method

A description of the URL parameters is as follows:

  • Schema: value of HTTP or HTTPS
  • Bucket: the user’s OSS storage space
  • Endpoint: the access domain name for a bucket’s data center
  • Object: an object uploaded by a user to the OSS

Notes

  • When the resource is a bucket, the endpoint must be consistent with the region containing the bucket. For example, if a bucket is created in Hangzhou, the Hangzhou endpoint must be used. Endpoints for other regions cannot be used.
  • To access the OSS, ECS instances can use the intranet endpoint for OSS resources in the same region.
  • For a list of regions and their endpoints, refer to Regions and endpoints.

If a user uses HTTPS to send a request to the Hangzhou OSS for an object named mytest/oss-test-object in a bucket named oss-sample, the third-level domain name is as follows:

  1. https://oss-sample.oss-cn-hangzhou.aliyuncs.com/mytest/oss-test-object

Users can directly use object URLs in HTML, as shown below:

  1. <img src="https://oss-example.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png" />

OSS access security

HTTP requests sent to the OSS are divided into two types depending on whether they include identity authentication information: Requests with identity verification information, and anonymous requests without identity verification information. The identity verification information in requests can be structured in two ways:

  • Authorization is contained in the request header, in the format: OSS + AccessKeyId + signature string.
  • OSS AccessKeyId and signature fields are contained in the request URL.

OSS access verification process

Anonymous request access process

  1. The user’s request is sent to the OSS’s HTTP server.
  2. OSS resolves the URL to get the bucket and object.
  3. OSS checks whether ACL is set for the object.
    • If no, go to Step 4.
    • If yes, OSS then checks whether the object’s ACL permits anonymous access.
      • If yes, go to step 5.
      • If no, the request is rejected and the process ends.
  4. OSS checks whether the bucket’s ACL permits anonymous access.
    • If no, an error message is returned and the process ends.
    • If yes, go to step 5.
  5. The request passes permission verification and the object content is returned to the user.

Access process for requests with ID verification information

  1. The user’s request is sent to the OSS’s HTTP server.
  2. The OSS resolves the URL to get the bucket and object.
  3. Based on the request’s OSS AccessKeyId, the OSS retrieves the ID information of the requestor for authentication.
    • If the ID information cannot be obtained, an error message is returned and the process ends.
    • If the ID information is obtained, but the client is not permitted to access this resource, an error message is returned and the process ends.
    • If the ID information is obtained, but the signature calculated based on the request’s HTTP parameters does not match the sent signature, an error message is returned and the process ends.
    • If the authentication succeeds, go to step 4.
  4. OSS checks whether ACL is set for the object.
    • If no, go to Step 5.
    • If yes, OSS then checks whether the object’s ACL permits anonymous access.
      • If yes, go to step 6.
      • If no, the request is rejected and the process ends.
  5. OSS checks whether the bucket’s ACL permits anonymous access.
    • If yes, go to step 6.
    • If no, an error message is returned and the process ends.
  6. The request passes permission verification and the object content is returned to the user.

Methods for OSS access using ID verification information

  • Console
    On the console, the identity verification process is concealed from users. When users access the OSS through the console, they do not have to concern about the details of this process.
  • SDKs
    The OSS provides SDKs for multiple development languages. A signature algorithm is implemented in an SDK, where users only need to input the AK information as a parameter.
  • APIs
    If you want to write your own code to package a call to the RESTful API, you need to implement a signature algorithm to calculate the signature. For details about the signature algorithm, refer to Adding a signature to the header and Adding a signature to the URL.

Note: For an explanation of AccessKeys, as well as more information on identity authentication operations, refer to RAM.

Thank you! We've received your feedback.