これについて、
1. 私の現在のアプローチは、まずaccess_tokenとそれに対応する取得時刻をデータベースに保存し、現在のリクエスト時刻とデータベースとの時間差が一定時間(6000秒)を超えているかどうかを確認することです。 、access_token を再リクエストし、トークンと時間を再保存します。そうでない場合は、データベース内の既存のトークンを直接使用してチケットをリクエストします。
2. 質問: 1) チケットを複数回リクエストすることは可能ですか?トークンは複数回要求されなければ大丈夫でしょうか?
2) 同じトークンでチケットをリクエストする場合は異なりますか?トークンとチケットの関係は何ですか?
ありがとう!
これについては、
1. 現在のアプローチは、まず access_token とそれに対応する取得時刻をデータベースに保存し、現在のリクエスト時刻とデータベースとの時間差が一定時間 (6000 秒) を超えているかどうかを確認することです。 、access_token を再リクエストし、トークンと時間を再保存します。そうでない場合は、データベース内の既存のトークンを直接使用してチケットをリクエストします。
2. 質問: 1) チケットを複数回リクエストすることは可能ですか?トークンは複数回要求されなければ大丈夫でしょうか?
2) 同じトークンでチケットをリクエストする場合は異なりますか?トークンとチケットの関係は何ですか?
ありがとう!
「WeChat パブリック プラットフォーム インターフェイス デバッグ ツール」の個人的な経験を通じて、次の結論が導き出されます:
1. WeChat パブリック プラットフォーム開発文書には次のように記載されています。
WeChat パブリック プラットフォームには jsapi_ticket の呼び出しの数と頻度に制限があることがわかります。jsapi_ticket を頻繁に更新することはお勧めできませんが、更新されないと機能しません。次に、チケットには WeChat を呼び出すための api_ticket が含まれています。 jssdk 設定に使用されるクーポンと jsapi_ticket (引き換えに使用されます)。QR コード チケットのルールは同じです。
2. 同じ access_token が同じチケット結果を複数回取得します。ただし、WeChat では、access_token とチケットをグローバルにキャッシュし、対応する有効期限を設定することをお勧めします。両者の違いについては、個人的には次のように考えています。
ticket は特定の API の呼び出し証明書です。ある程度漏洩しても問題はありません。特定の権限が含まれているだけです。 access_token は、パブリック アカウントのグローバルに一意なインターフェイス呼び出し資格情報です。パブリック アカウントは、各インターフェイスを呼び出すときに access_token を使用する必要があり、適切に保持する必要があります。チケットはトークンによって生成される一時的な認証情報です。再取得すると、以前の認証情報は無効になります。