Platform functions-Introduction to sub-account authorization transformation and upgrade


Content of transformation

The content of this transformation is divided into Two pieces, The first is the transformation of the sub-account session key; The second is the transformation of the sub-account authorization mode;

①. Sub-account sessionkey modification, mainly affects ISV (third-party application developers)

  • Before transformation: The authorization code sessionkey value obtained by logging in with the sub-account is consistent with that of the main account;
  • After transformation: Issue a regenerated sessionkey value to the sub-account, which is related to the main sessionkey but has different parameter values. The sub-sessionkey authorization duration is consistent with the main sessionkey, and the main and sub-sessionkeys are supported to be refreshed independently. The validity period of the high-risk read and write API, sub-account authorization method and return parameter analysis remain unchanged;

②. The transformation of the sub-account authorization model mainly affects users; (Please click on the user authorization process after the transformation)

  • Before transformation: Only support access rights of all sub-accounts to third-party applications;
  • After transformation : Can support authorizing third-party applications through roles or authorizing third-party applications individually for individual sub-accounts;

Transformation scope

##As long as the application supports sub-accounts, it will take effect; (This transformation does not apply to the Wangwang plug-in category for the time being) Apply to take effect)

Purpose of transformation

For users:

①. Protect user data security; Later, API permissions will be restricted at the API level based on different sub-account session keys with different permissions (still under planning);

②. Multiple applications use one account system; a seller will use multiple ISV systems, such as ERP, CRM, etc., and can use one account system;

③. Employees can use the system according to their roles; the seller’s main account can decide whether to grant system usage permissions based on employee permissions and roles;

For ISVs and merchants:

①. Log monitoring; use sub- The session key of the account is convenient for recording the source of the operation and doing security log monitoring; and the official will open the operation log for users to query, and further record the most accurate operator; (Currently, the officially recorded operation logs are based on the parent account, because the child account The account session key directly uses the parent account. After the transformation, it will be made to inherit the control of the child session key);

Note:

##Log query entry: in sub-account management Query in the "operation log" of the system;

Monitoring business scope: mainly a few core businesses, such as commodities, transactions, etc. Modification, deletion and other operations, so the monitored APIs are only some high-risk APIs;

Scope of monitoring objects: all supported sub-accounts and Third-party applications that call high-risk monitoring APIs such as modifying prices, and corresponding operation records in the Taobao backend;

Open log content: record only Behavior does not record the specific API, specific to the operator nick, time, appkey (if it is a third-party application), operation content, etc.;

Sub-account sessionkey effective rules

  • The authorization validity period of the sub-sessionkey is equal to that of the main sessionkey. When the main account sessionkey expires, the sub-sessionkey also becomes invalid; if the sub-account cannot be authorized, a prompt will be given;

  • If the main account cancels authorization for a sub-account in "Sub-Account Management", all external session keys of the sub-account will become invalid; Prompt when authorization cannot be given;
  • On the premise that the sub-sessionkey is valid, the master and sub-accounts can refresh their R1, R2, and W1 respectively. , W2 four durations, and are not affected by each other; (for details, see //open.taobao.com/doc/detail.htm?id=1002);
  • The sub-account is authorized for the first time and the short authorization verification requires the authorization page to pop up. If the authorization cannot be successful, the reason will be prompted.

##Sub-account sessionkey issuance rules

  • ##Old authorization method: TOP authorization switch, control all Subaccount is available or unavailable.

a. For the old authorization method: cancel the big switch of TOP authorization for sub-accounts, and cancel the two entrances:

            1. On the authorization page of TOP, cancel the check box of the authorized sub-account, as shown in Figure (1);

          2. Modify the application authorization page in account management and cancel the functions in the red box below, as shown in Figure (2);

T1OpnvXdJqXXb1upjX.jpg

Picture (1)

T17O2wXnBkXXb1upjX.jpg

##Picture (2)

## b. The authorization of the main account to the sub-account is set in the "Sub-Account Management" in the Seller Center, and the official will Pushed to TOP, TOP will only issue sub-session keys to sub-accounts with access rights, otherwise it will not be issued.

  • New authorization method: TOP cancel authorization switch, the user selects sub-account authorization in "Seller Center---Sub-account Management" (can be authorized through roles, or directly Authorization of a certain sub-account), as shown in Figure (3) and Figure (4).

a. Enter "Seller Center—Sub Account Management—Employee Management—Organizational Structure" and select you Employee sub-account to be edited or new employee: T13bvxXolhXXb1upjX.jpg

T1JQTxXkJcXXb1upjX.jpg

T1XHjwXbBmXXb1upjX.jpg##Picture (3): Directly authorize a sub-account

## b. Go to "Seller Center—Sub-Account Management—Employee Management—Role Management" and select a role to be edited ：

T1zA6xXb8cXXb1upjX.jpg

Figure (4): Role authorization

## Sub-account authorization switching rules

## a. For APPs that already support sub-accounts, ISVs are allowed to switch independently, and they will appear in the UP list later. Switch the button "Upgrade sub-account authorization mode", click the pop-up window to confirm the prompt , The mode as shown below will be uniformly switched after 2 months;

T1NxHxXhNdXXb1upjX.jpg

T1f5YxXeJeXXb1upjX.jpg

b. For For APPs that do not support sub-accounts, if you choose to support sub-accounts after the project is launched, you must use the modified sub-account session key.

ISV modified content

Old APP that already supports sub-accounts

① Program changes:

A. During the sub-account login process, cancel the direct use of the session key of the parent account process, reuse the authorization method provided by TOP to obtain the authorization

              code, appkey and appsecret will not be changed;

##                                                                                                                                                                                                  ’ Modified to accept multiple ones at one time (stored in array form) to avoid the phenomenon of

# being kicked offline within a short period of time;

## ② Click the switch button in the UP list and go to TOP Developer Center → Application Management → Application List, as shown in the picture of "Sub-Account Authorization Switching Rules";

##Old APPs that do not support sub-accounts

## ① In the TOP application management→Manage authorization interface, add "Whether Taobao sub-accounts are supported" Account login", as shown in the picture:

## ② The program reference content is as above;

T1DLPxXmFdXXb1upjX.jpg

Newly applied APP

## ① Application After creation, in the TOP Application Management → Management Authorization interface, select "Whether Taobao sub-account login is supported", as above;

② The program reference content is as above;

Sub-account authorization system

l Login verification authorization method based on OAuth2.0 (officially recommended): //open.taobao.com/doc/detail.htm ?id=118 (For APIs that use

and use short , it is recommended to use this authorization agreement);

#How to know whether the current user is a sub-account? By parsing the json format returned, the parsing returns sub_taobao_user_id and sub_taobao_user_nick. See document 2.2 for specific methods;

##l Based on Login authorization method of TOP protocol: //open.taobao.com/doc/detail.htm?id=105 (Short authorization is supported API, but it is not recommended to use

##)

#How to know whether the current user is a sub-account? By parsing the returned top_paramater parameter, please refer to //open.taobao.com/doc/detail.htm?spm=0.0.0.181.wmACQo&id=110

##

ISV transformation process suggestions

① Background scheduled polling operation

For functional operations such as scheduled order downloads, scheduled product listings, and scheduled inventory changes implemented by the application, you can keep using the locally cached main account session key,

Because once the sub-account is closed or expires, the session key of the sub-account will become invalid, causing the application timing function to not work properly;

##② Daily operations

For daily operation functions, such as price modification, attribute modification, etc., the official strongly recommends that the session key of the current session be used as the basis for calling, especially operations that call high-risk APIs (delete and modify operations). ; In the future, the official will make high-risk API writing operations inherit the control of sub-sessionkeys, and relevant operation records will be recorded to the corresponding sub-accounts to achieve the most accurate security monitoring (this part of the official log information will be unified and open in the future);

##③ Single app single sessionkey

For self-use applications such as merchant backends, isv general procedures The setting is to hard-code the appkey and accept one session key (parent account sk). After the sub-account authorization code is modified (different sub-accounts have different session keys), account system applications that support multiple sub-accounts need to be set to accept multiple session keys to avoid multiple account logins. The phenomenon of being pushed offline;

④ Judge whether the session key is valid in time

  • For locally saved session keys, it is recommended that the user compares the currently returned new session key with the locally saved old session key corresponding to the user after each login. If they are inconsistent, overwrite them with the new session key. The old session key maintains the validity of the session key; because the Taobao sub-account is in arrears, deactivated, the main account has canceled the authorization of an application, W2 has expired and has not been re-logged in, and R has expired and has not been refreshed, the old session key of the corresponding sub-account It will become invalid. If it is reused later, a new sessionkey will be reissued;

  • ##Not saved locally, each time the user logs in to obtain the current session key; (recommended) the current TOP authorization system, before the session key expires, each login will directly enter the system and return the same session key. If If the session key expires or the session key expires, subsequent logins will jump back to the authorization page and return the newly issued session key, so the session key returned by the current login will always be the latest; (for the function of using the parent account's background scheduled polling operation, it is still recommended to keep The session key of the parent account is saved locally)

##Sub-account API

Reference for calling details: //open.taobao.com/doc/api_cat_detail.htm?cat_id=10123&category_id=102;FAQ

There is no FAQ
  • about this document yet.
←
→