0

個人用アクセス トークンを使用してアクセスし、アイテムのリストを取得するアプリケーションがあります。OAuth の使用に切り替えたいのですが、アプリケーションは ITEMS_READ のみを使用します。

私のアプリケーションは、このアプリケーション専用の安全な Ubuntu サーバーのインスタンスで実行されるデーモンです。「アプリケーション サーバー」に関して、square が推奨するものはありますか? 「アプリケーション サーバー」の一般的なベスト プラクティスは何ですか?

ありがとうございました

4

1 に答える 1

1

API のドキュメントはかなり充実しており、OAuth に関する役立つセクションが含まれています。過去に OAuth 実装で気付いたいくつかの一般的な落とし穴から、次のことを指摘するようになりました。

  1. 自分で使用するために 1 回限りの統合を構築するだけの場合は、おそらく OAuth を使用する価値はありません。
  2. OAuth の仕組みを理解していることを確認してください。ユーザーのクライアント シークレットや個人アクセス トークン、または connect.squareup.com でアプリ管理ダッシュボードを開く必要があるその他のことを求めている場合は、実装を再考する必要があります。アクセス トークンやその他の API 資格情報を理解する必要があるのは、開発者であるあなただけです。
  3. 一般に、必要最低限​​の OAuth スコープよりも多くの OAuth スコープを要求できます。MERCHANT_PROFILE_READ も取得することをお勧めします。これはアカウントを管理するのに便利なので、ヒット/v1/meして必要なさまざまな ID を取得できます。
  4. Square OAuth アクセス トークンは、こちらで説明されているように有効期限が切れます。それらは 30 日間続くため、これに気付いていない開発者に忍び寄る傾向があります。スケジュールされたタスクを使用して、有効期限が近づいているアクセス トークンを更新し、更新後に古いトークンを消去する必要があります。cronjob のような単純なもので十分です。

使用するテクノロジー スタックに関しては、それは完全にあなた次第です。Square Connect チームは、可能な場合は喜んでお手伝いし、推奨事項を提供します。

于 2015-06-25T09:11:59.090 に答える