変換の内容

この変換の内容は 2 つの部分に分かれており、最初の はサブアカウントのセッション キーの変換です; 2 番目の はサブアカウントの認証モードの変換です;

①. サブアカウントのセッションキーの変更、 は主に ISV に影響します (3 番目-パーティアプリケーション開発者)

• 変換前: サブアカウントでログインして取得した認可コードのsessionkeyの値が一致している
• 変換後: 再生成されたセッションキー値をサブアカウントに発行します。メインセッションキーと同じですが、パラメータ値が異なります サブセッションキーの認証期間はメインセッションキーと一致しており、メインセッションキーとサブセッションキーは個別に更新されるようにサポートされています 高リスクの読み取りおよび書き込みAPIの有効期間、サブセッションキーアカウント認証方法と戻りパラメータ分析は変更されません;

②サブアカウント認証モデルの変換は主にユーザーに影響します; (変換後のユーザー認証プロセスをクリックしてください)

• 変換前 : サードパーティ アプリケーションに対するすべてのサブアカウントのアクセス権のみをサポート;
• 変換後 : サポート可能ロールを通じてサードパーティ アプリケーションを承認するか、個々のサブアカウントに対して個別にサードパーティ アプリケーションを承認します。

# 変換スコープ

##アプリケーションがサブアカウントをサポートしている限り、それは有効になります; (この変換は当面は Wangwang プラグイン カテゴリには適用されません) 有効にするには適用してください)

#変換の目的

ユーザー向け:

①. ユーザー データのセキュリティを保護する ; その後、API 権限は、異なる権限を持つ異なるサブアカウント セッション キーに基づいて API レベルで制限されます (まだ計画中です);

#②. 複数のアプリケーションが 1 つのアカウント システムを使用します; 販売者は ERP、CRM などの複数の ISV システムを使用し、1 つのアカウント システムを使用できます。

##③. 従業員は役割に応じてシステムを使用できます; 従業員に基づいてシステムの使用許可を与えるかどうかは販売者のメインアカウントが決定できます権限と役割;

ISV および販売者向け:

①.ログ監視; サブアカウントのセッション キーを使用すると、操作のソースを記録し、セキュリティ ログの監視を行うのに便利です。公式はユーザーが照会できるように操作ログを開き、最も正確な操作者をさらに記録します。 ; (現時点では、子アカウントのアカウントセッションキーは親アカウントを直接使用しているため、正式に記録される操作ログは親アカウントをベースとしています。変換後は子セッションキーの制御を引き継ぐことになります); # ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃注記： ＃＃＃＃＃＃ ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

##ログ クエリ エントリ: サブアカウント管理内 システムの「操作ログ」のクエリ;

監視業務範囲: 主に、商品、トランザクションなどの少数の基幹業務。変更、削除、その他の操作。したがって、監視対象 API は一部の高リスク API のみです。

#監視オブジェクトの範囲: サポートされているすべてのサブアカウントと、価格の変更などの高リスク監視 API を呼び出すサードパーティ アプリケーション、およびタオバオ バックエンドの対応する操作レコード;

オープン ログ コンテンツ: 記録のみ 動作は、特定の API を記録しません。オペレーターのニックネーム、時刻、アプリキー (サードパーティ アプリケーションの場合)、操作内容など;

#サブアカウント セッションキーの有効なルール

• ##サブ セッション キーの認証有効期間は、メイン セッション キーと同じです。メイン アカウントのセッション キーの有効期限が切れると、サブ セッション キーも無効になります。サブ アカウントを認証できない場合は、次のプロンプトが表示されます。

• メインアカウントがサブアカウントの承認をキャンセルした場合「サブアカウント管理」、サブアカウントのすべての外部セッションキーが無効になります; 認可できない場合のプロンプト;

• サブセッションキーが有効であることを前提として、マスターアカウントとサブアカウントはそれぞれ R1、R2、W1 を更新できます。W2 は 4 つの期間であり、相互に影響を受けません。(詳細は //open を参照) .taabao.com/doc/detail.htm?id=1002);

• サブアカウントが初めて承認されました短い認証検証では、認証ページがポップアップする必要があります。認証が成功しない場合は、その理由を尋ねるメッセージが表示されます。

##サブアカウントのセッションキー発行ルール

• ##古い認可方法: TOP認可スイッチ、すべてのサブアカウントを制御利用可能か利用不可か。

a. 古い認証方法の場合: サブアカウントの TOP 認証の大きな切り替えをキャンセルし、2 つの入り口をキャンセルします:

1. 図(1)に示すように、TOPの承認ページで、承認されたサブアカウントのチェックボックスをオフにします。

## 2. 図 (2) に示すように、アカウント管理のアプリケーション認証ページを変更し、下の赤枠の機能をキャンセルします。

#

写真 (1)

#写真 (2)

## b. メインアカウントのサブアカウントへの権限は、セラーセンターの「サブアカウント管理」で設定します。そして公式はTOPにプッシュされ、TOPはアクセス権のあるサブアカウントにのみサブセッションキーを発行し、それ以外の場合は発行されません。

• 新しい認証方法: TOP 認証スイッチをキャンセルすると、ユーザーは「セラー センター---サブアカウント管理」でサブアカウント認証を選択します (ロールを通じて、または直接認証できます)図 (3) および図 (4) に示すように、特定のサブアカウントの認可)。

a. 「セラーセンター - サブアカウント管理 - 従業員管理 - 組織構造」と入力し、選択します。編集する従業員のサブアカウントまたは新しい従業員:

##画像(3): サブアカウントを直接承認する

## b. 「セラーセンター - サブアカウント管理 - 従業員管理 - ロール管理」に移動し、編集するロールを選択します：

図 (4): ロールの権限

## サブアカウント認可切り替えルール

## a. すでにサブアカウントをサポートしているアプリの場合、ISV は独立して切り替えることができ、サブアカウントが表示されます。 「サブアカウント認証モードのアップグレード」ボタンを切り替え、ポップアップ ウィンドウをクリックしてプロンプトを確認します

, 以下に示すモードは、2 か月後に一律に切り替わります。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ ## b. サブアカウントをサポートしていないアプリの場合、プロジェクトの起動後にサブアカウントをサポートすることを選択した場合は、変更されたサブアカウント セッション キーを使用する必要があります。

#ISV 変更コンテンツ

#既にサブアカウントをサポートしている古いアプリ

① プログラムの変更:

A. サブアカウントのログインプロセス中に、サブアカウントの直接使用をキャンセルします。親アカウントプロセスのセッションキーを取得するには、TOP が提供する認可メソッドを再利用して認可を取得します。

# Code、 AppkeyとAppSecretは変更されません;

# ’一度に複数のものを受け入れるように変更されました（保存されています

# 短期間でオフラインになる現象を避けるため;

## ② UP リストの切り替えボタンをクリックし、「サブアカウント権限切り替えルール」の図に示すように、TOP デベロッパー センター → アプリケーション管理 → アプリケーション リストに移動します。

古いアプリサブアカウントをサポートしていない

## ① TOPのアプリケーション管理→認証管理インターフェースで、「淘宝網のサブアカウントがサポートされているかどうか」を追加します アカウントログイン

## ② プログラムのリファレンス内容は上記の通りです;

新規申請アプリ

## ①アプリケーション作成後、TOPの「アプリケーション管理」→「管理認証」インターフェースで、上記のように「淘宝網サブアカウントログインをサポートするかどうか」を選択します;

② プログラム参考内容は上記の通りです。

サブアカウント認可システム

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

l OAuth2.0 に基づくログイン検証承認方法 (公式推奨): //open.taabao.com/doc/detail.htm ? id=118 (

と短い を使用する API の場合は、この認可契約 を使用することをお勧めします。 );

#現在のユーザーがサブアカウントかどうかを確認するにはどうすればよいですか?返された json 形式を解析すると、sub_taabao_user_id と sub_taabao_user_nick が返されます。具体的な方法については、ドキュメント 2.2 を参照してください。

##l # に基づく# TOP プロトコルのログイン認証方法: //open.taabao.com/doc/detail.htm?id=105 (ショート認証はサポートされています API ただし、

## の使用はお勧めしません)

#現在のユーザーがサブアカウントかどうかを確認するにはどうすればよいですか?返された top_paramater パラメーターを解析して、//open.taabao.com/doc/detail.htm?spm=0.0.0.181.wmACQo&id=110 # を参照してください。

#ISV 変換プロセスの提案

① バックグラウンドでスケジュールされたポーリング操作

アプリケーションによって実装される、スケジュールされた注文のダウンロード、スケジュールされた製品リスト、スケジュールされた在庫の変更などの機能操作では、ローカルにキャッシュされたメイン アカウントのセッション キーを引き続き使用できます。

なぜなら、サブアカウントが閉鎖されるか期限切れになると、サブアカウントのセッション キーが無効になり、その結果、アプリケーションのタイミング機能が正常に機能できません。

##② Daily操作

価格変更、属性変更などの日常的な操作機能については、担当者は現在のセッションのセッション キーを使用することを強く推奨します。特に高リスク API を呼び出す操作 (削除および変更操作) の呼び出しの基礎として使用される可能性があります。将来的には、公式は高リスク API 書き込み操作にサブセッションキーの制御と関連する操作記録を継承させる予定です。最も正確なセキュリティ監視を実現するために、対応するサブアカウントに記録されます (公式ログ情報のこの部分は将来的に統合され、公開される予定です);

##③ 単一アプリ単一sessionkey

マーチャント バックエンドなどの自己使用アプリケーションの場合、一般的な手順です。設定は、セッション キー (親) を受け入れるハードコードされた appkey です。サブアカウント認証コードが変更された後 (サブアカウントごとにセッション キーが異なります)、複数のアカウント ログインを避けるために、複数のサブアカウントをサポートするアカウント システム アプリケーションは複数のセッション キーを受け入れるように設定する必要があります。オフラインにされる;

④ セッションキーが期限内に有効かどうかを判断します

• ローカルに保存されたセッション キーの場合、ログインのたびに、現在返されている新しいセッション キーと、そのユーザーに対応するローカルに保存されている古いセッション キーを比較することをお勧めします。 、新しいセッション キーで上書きします。古いセッション キーはセッション キーの有効性を維持します。淘宝網のサブアカウントが延滞していて非アクティブ化されているため、メイン アカウントがアプリケーションの認証をキャンセルしており、W2 の有効期限が切れており、再ログインされ、R が期限切れで更新されていない場合、該当するサブアカウントの古いセッション キーは無効になります。後で再利用される場合は、新しいセッション キーが再発行されます;

• ##ユーザーがログインして現在のセッションを取得するたびに、ローカルに保存されません。キー; (推奨) 現在の TOP 認証システムでは、セッション キーの有効期限が切れる前に、各ログインは直接システムに入り、同じセッション キーを返します。セッション キーの有効期限が切れた場合、またはセッション キーの有効期限が切れた場合、後続のログインは、認証ページを実行し、新しく発行されたセッション キーを返すため、現在のログインによって返されるセッション キーは常に最新になります (親アカウントのバックグラウンドでスケジュールされたポーリング操作を使用する機能については、引き続き、認証ページのセッション キーを保持することをお勧めします)。親アカウントはローカルに保存されます)

サブアカウント API

##通話詳細のリファレンス: //open.taovao.com/doc/api_cat_detail.htm?cat_id=10123&category_id=102;FAQ

があります。このドキュメントに関する FAQ

はまだありません。