Platform functions - scope of influence of sub-account authorization transformation and upgrade


Scope of transformation

##The transformation content is mainly divided into two parts. The first is the transformation of the sub-account session key; The second is the transformation of the sub-account authorization mode;

Sphere of influence

l The transformation of the sub-account sessionkey mainly affects third-party application developers (ISV), see Table (1) for details;

##ISVInfluence

Transformation of the former

After transformation

## Sub-account

sessionkey

sessionkey obtained by sub-account authorization

is taken from the same session key as the main account, and the operation records cannot be distinguished based on the session key;

The sub-account session key distinguishes the main session key. The main account and the sub-account are issued different session keys. The sub-account can be directly identified through the sub-session key (the official bottom layer will identify the parent-child relationship);

sessionkey authorization duration

The main sessionkey is used, high risk The api refresh duration requires the main account operation to be implemented

The sub-sessionkey authorization duration is consistent with the main sessionkey, and the main and sub-sessionkeys are supported to refresh high-risk reads and writes independently API validity period

Sub-account

Validity of sessionkey calling API

If a third-party application cancels the logic of supporting sub-accounts, it can still pass The saved sub-sessionkey calls the API operation, and the background sessionkey has not expired

Once a third-party application cancels support for sub-account logic, TOP will control itself and disallow all sub-sessionkey calling API requests; if a third-party application chooses to support sub-accounts, TOP will follow the MMP The provided authorization relationship controls the sub-sessionkey;

##Authorization system

Use the container authorization or oauth2 authorization method provided by TOP, and obtain user information by parsing the returned paramater parameter

remains unchanged, using the same authorization system

##Backend Polling operations (such as scheduled order downloads, etc.)

Use the main account sessionkey cached locally

Recommendation:

remains unchanged and still applies to the main account sessionkey to avoid being affected by the authorization code invalidation of the sub-account due to closure or arrears;

## Daily operations

Partially uses the main account sessionkey cached locally

Suggestion:

Use the current session key as the basis for the call, that is, each time the sub-account logs in, the currently returned session key will be obtained, without saving. Locally, especially when calling high-risk APIs, Taobao officials will directly record logs based on the identity of the session key that calls the API and open them to users for query. If you still use the main sessioneky, the log will not record the accurate sub-account (this part of the official log information will be unified and open in the future);

App supports sub-accounts

The "Manage Authorization" setting in the TOP application details allows sub-account authorization to use this function.

remains unchanged. Whether the application supports the sub-account system still requires isv setting as the first condition;

Before the transformation, was already supported. You can switch to the new mode in the UP application list. For details, please refer to "Sub-account authorization transformation and upgrade introduction》Document

After the transformation, if the newly created application is checked If selected, the new authorization mode will be used by default;

 

Table (1)

l The transformation of the sub-account authorization model mainly affects users, as follows;

Before transformation

##There are two ways for the main account to set whether the sub-account can access the application: The first method: When the main account uses the TOP container to log in, select "Authorize the sub-account to use this application";

T1ltLuXcdsXXb1upjX.jpg

## The second type: Taobao backend settings;
The user logs in to taobao.com and sets the "Application Authorization" in the account management to allow sub-account authorization;

T1F4TDXiJhXXb1upjX.jpg

After transformation

l

TOP’s two major authorization switches will make the following changes:

T1DVYxXdFiXXb1upjX.jpg

T1IdrwXf0lXXb1upjX.jpg

##

l New sub-account management system:

## There are two types of permissions for the main account to set sub-accounts. One is to authorize application permissions individually for a single sub-account. The second is to authorize third-party applications through roles, as follows:

The first one: Authorize a certain application permission to a single sub-account, as shown below:

## Enter "

Seller Center—Sub-Account Management—Employee Management—Organizational Structure", select the employee sub-account you want to edit or create a new employee:

T1IbLwXjXoXXb1upjX.jpg

T1cnnwXiBhXXb1upjX.jpg

T1YFbyXiVXXXb1upjX.jpg

Second: Grant application permissions to a role (all sub-accounts under this role have access to the application Permissions), as shown below:

Enter "

Seller Center—Sub Account Management—Employee Management—Role Management" and select a certain The role to edit.

T1uJvxXbBdXXb1upjX.jpg

Note: For those who have previously authorized sub-accounts in the old mode app, after the transformation, a role of "Application Service Access Rights" will be automatically created by default in the role management interface, and the role will be granted to existing sub-accounts by default. Users can This role can be modified and deleted accordingly, and the authorization relationship can also be modified for a single sub-account ;

l The main account can view the list of apps ordered under it that support sub-account login, and the list of sub-accounts that the corresponding app has currently authorized, as shown in the figure:

T1wGjrXkxtXXb1upjX.jpg

T1MFTyXgdXXXb1upjX.jpg

##FAQ

    There is no FAQ about this document
←
→