Sous-compte

sessionkey

La clé de session obtenue avec l'autorisation du sous-compte

est extraite de la même clé de session que le compte principal, et l'enregistrement de l'opération ne peut pas être distingué en fonction de la clé de session ;

La clé de session du sous-compte distingue la clé de session principale. Le compte principal et le sous-compte émettent des clés de session différentes. Le sous-compte peut être directement identifié grâce à la clé de sous-session (la officielle). la couche inférieure identifiera la relation parent-enfant);

heure d'autorisation de la clé de session

utilise la clé de session principale, et le temps d'actualisation de l'API à haut risque doit être implémenté par le compte principal

Le temps d'autorisation de la clé de sous-session est cohérent avec la clé de session principale, et les clés principale et de sous-session sont prises en charge pour actualiser indépendamment la validité de l'API de lecture et d'écriture à haut risque. période

Sous-compte

Validité de l'API d'appel de sessionkey

Si une application tierce annule la logique de prise en charge sous-comptes, cela peut passe toujours La clé de sous-session enregistrée appelle l'opération API et la clé de session en arrière-plan n'a pas expiré

Une fois qu'une application tierce annule la prise en charge de la logique de sous-compte, TOP se contrôlera et n'autorisera pas toutes les demandes d'API d'appel de sous-session si l'application tierce choisit de prendre en charge les sous-comptes, TOP le fera ; contrôler la clé de sous-session en fonction de la relation d'autorisation fournie par MMP

Système d'autorisation

Utilisez la méthode d'autorisation de conteneur ou oauth2 fournie par TOP et obtenez des informations sur l'utilisateur ; en analysant les paramètres de paramètres renvoyés

Aucun changement, utilisez le même système d'autorisation

Opérations d'interrogation en arrière-plan (telles que les téléchargements de commandes planifiés, etc.)

Utilisez la clé de session du compte principal mise en cache localement

Recommandations :

reste inchangée et la clé de session du compte principal est toujours applicable pour éviter d'être affecté par l'invalidation du code d'autorisation du sous-compte pour cause de fermeture ou d'arriérés

Opérations quotidiennes

Utilisez en particulier le compte principal SessionKey Cached Locally

CecomMendation:

basé sur la SessionKey de la session en cours comme base d'appel, c'est-à-dire chaque fois que le le sous-compte se connecte L'obtention de la clé de session actuellement renvoyée n'a pas besoin d'être enregistrée localement, en particulier lors de l'appel d'API à haut risque, car les responsables de Taobao se connecteront directement en fonction de l'identité de la clé de session appelant l'API et l'ouvriront aux utilisateurs pour requête. Si vous utilisez toujours la session principale, le journal n'enregistrera pas le sous-compte précis (cette partie des informations du journal officiel sera unifiée et ouverte à l'avenir

L'application prend en charge les sous-comptes) ; comptes

Le paramètre « Gérer l'autorisation » dans les détails de l'application TOP permet l'autorisation de sous-compte pour utiliser cette fonction.

reste inchangé. La prise en charge par l'application du système de sous-compte nécessite toujours les paramètres ISV comme première condition

Avant la transformation, cela était déjà pris en charge et peut l'être ; mis à jour. La liste des applications Pour effectuer un changement indépendant et passer à un nouveau mode, veuillez vous référer au document « Introduction à la transformation et à la mise à niveau de l'autorisation de sous-compte »

Après la transformation, si l'application nouvellement créée est cochée, elle passera par défaut au nouveau mode d'autorisation ;