In the era of mobile Internet, data upload using mobile apps is increasingly common. It is expected that logs in mobile apps are directly uploaded to Log Service, instead of being transferred by an app server, so that users can focus more on their business logic development.
In normal mode, the AccessKey of the primary account is required when logs are written into Log Service for authentication and anti-tampering. If a mobile app accesses Log Service in this mode, your AccessKey must be stored on the mobile end, causing a data security risk of AccessKey disclosure. Once the AccessKey is disclosed, you must upgrade the mobile app and replace the AccessKey, which is quite expensive. Another way to upload logs on the mobile end to Log Service is to use the user’s app server. However, in this mode, if the number of mobile apps is large, the app server must carry all the data on the mobile end. This mode has a high requirement on the server size.
To avoid preceding problems, Log Service provides more secure and convenient scheme to collect mobile app logs. It uses RAM to set up direct data transfer for mobile apps based on mobile services. In contrast to the scheme of directly using the AccessKey to access Log Service, this scheme does not require AccessKey storing on the app end, eliminating the risk of AccessKey disclosure. A temporary token with a lifecycle gives more safety. You can also configure more complex access control policies for the token, for example, limiting the access permission of the IP segment. The cost of this scheme is low. You do not require many app servers because mobile app data is stored on the cloud platform and only the control flow is sent to the app server.
You can create a RAM user role of Log Service and configure an app as a RAM sub-account to assume this role, so that you can set up Log Service-based direct log transfer for mobile apps within 30 minutes. Direct data transfer is a service that allows mobile apps to directly connect to Log Service, with only the control flow sent to the app server.
Using RAM to set up Log Service-based direct data transfer for mobile apps has the following advantages:
- The access method is more secure, providing temporary flexible permission assignment and authentication.
- Low cost with fewer app servers. The mobile apps are directly connected to the cloud platform and only the control flow is sent to the app server.
- Log Service provides large upload and download bandwidths, high concurrency and support of massive users.
- Log Service allows unlimited storage space resizing, providing elasticity.
The architecture diagram is as follows:
|Android/iOS mobile app||The app running on the end user’s cell phone, and the source of logs.|
|LOG||Alibaba Cloud Log Service, responsible for storing log data uploaded by the app. For more information, see Log Service description on Alibaba Cloud website.|
|RAM/STS||Alibaba Cloud RAM provides the user identity management and resource access control services, and generates temporary access credentials.|
|App server||The app background service developed for the Android/iOS mobile app, and used to manage the tokens used for data upload/download by the app, and the metadata of the app-uploaded data.|
The app applies for a temporary access credentials from the app server.
To avoid the risk of information leakage, the Android/iOS app does not store the AccessKey ID and AccessKey Secret. Therefore, the app must request a temporary upload credentials (a token) from the app server. The token is only valid for a certain period. For example, if a token is set to be valid for 30 minutes (can be specified by the app server), the Android/iOS app can use this token to access Log Service within the next 30 minutes. 30 minutes later, the app must request a new token again.
The app server checks the validity of the request and then returns a token to the app.
After obtaining the token, the mobile app can access Log Service.
This document mainly describes how to apply for the token from RAM using the app server and how to obtain the token for Android/iOS apps.
Create a RAM user role of Log Service and configure an app as a RAM sub-account to assume this role. For more information, see Authorize a user role to operate Log Service.
After configuration, you can obtain the following parameters:
- AccessKey ID and AccessKey Secret of the RAM sub-account
- Resource path RoleArn of the role
This tutorial provides sample programs in multiple languages. The download URLs are listed at the end of this document.
Each downloaded language package contains the following configuration file config.json:
"AccessKeyID" : "",
"AccessKeySecret" : "",
"RoleArn" : "",
"TokenExpireTime" : "900",
- AccessKeyID: The ID of your AccessKey.
- AccessKeySecret: The secret of your AccessKey.
- RoleArn: The RoleArn of the user role.
- TokenExpireTime: The expiration time of the token obtained by the Android/iOS app. The minimum value is 900s and does not need to be changed.
- PolicyFile: The file that lists the permissions the token grants. The default value does not need to be changed.
This document provides two token files defining the most common permissions in the policy directory:
- write_policy.txt: Specifies a token that grants the write permission for the project to this account.
readonly_policy.txt: Specifies a token that grants the read permission for the project to this account.
You can design your policy file as required. For more information about the permissions, see Permission control of Log Service.
Format of the returned data:
//Returned correct result
"ErrorMessage":"Specified AccessKey is not found."
Description of the returned correct result, the following five variables comprise a token:
|StatusCode||The result that the app retrieves the token. The app returns 200 if the token is successfully retrieved.|
|AccessKeyId||AccessKey ID that the Android/iOS app obtains when initializing the Log client.|
|AccessKeySecret||AccessKey Secret that the Android/iOS app obtains when initializing the Log client.|
|SecurityToken||The token the Android/iOS app initializes.|
|Expiration||The time that the token expires. The Android SDK automatically determines the validity of the token and then retrieves a new one as needed.|
Description of the returned error:
|StatusCode||The result that the app retrieves the token. The app returns 500 if the token fails to be retrieved.|
|ErrorCode||The error cause.|
|ErrorMessage||The error description.|
Running method of the sample code:
For Java 1.7 and later versions, after downloading and decompressing the package, create a Java project, copy the dependency, code, and configuration to the project, and run the main function. The program listens to port 7080 and waits for the HTTP request by default. Perform the operations in other languages in a similar way.
The formats of the HTTP request and response are as follows:
Request URL: GET https://localhost:7080/
All examples in this document are used to demonstrate how to set up a server. You can implement custom development based on these examples.
Sample code of the app server