Development sequence diagram

Typical OSS-based app development involves the following four components:

  • OSS: Provides functions such as upload, download, and upload callback.
  • Developer's mobile client (mobile application or webpage application, called the client for short): Uses the service provided by the developer to access OSS.
  • Application server: Interacts with the client. This server is used for the developer's service.
  • Alibaba Cloud STS: Issues temporary credentials.

Best practices

Service development process

  • Data upload with temporary credential authorization

    The following figure shows the process of data upload with temporary credential authorization:



    The description of the process is as follows:

    1. The client sends the application server the request of uploading data to OSS.
    2. The application server sends a request to STS.
    3. STS returns temporary credentials (STS AccessKey and token) to the application server.
    4. The client obtains the authorization (STS AccessKey and token) and calls the mobile client SDK to upload data to OSS.
    5. The client successfully uploads data to OSS. If callback is not set, the process is complete. If callback is set, OSS calls the relevant interface.

    Note:

    • The client does not have to request authorization from the application server for each upload attempt. Each time the authorization is obtained, the client caches temporary credentials returned by STS until it expires.
    • STS provides fine-grained access control for upload, which restricts client access permissions at the object level. This completely isolates the objects uploaded to OSS by different clients, and thus greatly enhances application security.

    For more information, see Authorized third-party upload

  • Data upload with signed URL or form authorization

    The following figure shows the process of data upload with signed URL or form authorization:



    The description of the process is as follows:

    1. The client sends the application server the request of uploading data to OSS.
    2. The application server returns credentials (signed URL or form) to the client.
    3. The client obtains authorization (signed URL or form) and calls the mobile client SDK to upload data or uses form upload to directly upload data to OSS.
    4. The client successfully uploads data to OSS. If callback is not set, the process is complete. If callback is set, OSS calls the relevant interface.

    For more information, see Authorized third-party upload.

  • Data download with temporary credential authorization

    The process of data download with temporary credential authorization is similar to that of data download with temporary credential authorization:

    1. The client sends the application server the request of downloading data from OSS.
    2. The application server sends a request to STS and obtains temporary credentials (STS AccessKey and token).
    3. The application server returns the temporary credentials (STS AccessKey and token) to the client.
    4. The client obtains the authorization (STS AccessKey and token) and calls the mobile client SDK to download data from OSS.
    5. The client successfully downloads data from OSS.

    Note:

    • For download, the client also caches temporary credentials to increase access speed.
    • STS also provides fine-grained access control for download. The access control for both upload and download helps to isolate the OSS storage space for each mobile client.
  • Data download with signed URL authorization

    The process of signed URL authorization for download is similar to that of signed URL authorization for upload:

    1. The client sends the application server the request of downloading data from OSS.
    2. The application server returns the signed URL to the client.
    3. The client obtains authorization (signed URL) and calls the mobile client SDK to download data from OSS.
    4. The client successfully downloads data from OSS.
    Note
    The client cannot store the developer's accesskey, you can get only the URL signed by the application server or the temporary credentials issued via STS (that is, the access key of the STS. and token ).

Best practices

Reference