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);
Picture (1) ##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. a. Enter "Seller Center—Sub Account Management—Employee Management—Organizational Structure" and select you Employee sub-account to be edited or new employee: ## b. Go to "Seller Center—Sub-Account Management—Employee Management—Role Management" and select a role to be edited : Figure (4): Role authorization ## 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; 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. 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; ##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; 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; 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 ## ① 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 Reference for calling details: //open.taobao.com/doc/api_cat_detail.htm?cat_id=10123&category_id=102;FAQ##Picture (3): Directly authorize a sub-account
## Sub-account authorization switching rules
ISV modified content
ISV transformation process suggestions
##Sub-account API
about this document yet.