ちょっとした背景:現在、いくつかのベンダー間で HTTP API を指定して、異なる製品が簡単に相互運用できるようにしようとしています。「サーバー」ソフトウェアもクライアントもまだ作成していませんが、API の基本をレイアウトしているだけなので、すべての関係者がプロトタイピングを開始してから改良することができます。したがって、この API の典型的な使用例は、ブラウザー内からではなく、特定のアプリケーション内の (薄い) HTTP レイヤーによって使用されます。
ここでセッション状態がないとコミュニケーションは意味をなさないので、通常はセッションを追跡する方法を検討していました。
つまり、使用する HTTP ライブラリにできるだけ負担をかけずに、API の実装をできるだけ簡単に保ちたいということです。
誰かが、基本的に「URL 書き換え」によってセッションを管理することを提案しましたが、もう少し明示的です。
POST .../service/session{ ... }- => 返信
201 Createdとセッション URL の場所.../service/session/{session-uuid} - 後続のリクエストの使用
.../service/session/{session-uuid}/whatever - クライアントが行うセッションを終了する
DELETE .../service/session/{session-uuid}
Web を見回してみると、最初の検索では、これはやや異例であることがわかります。
これは有効なアプローチですか？具体的な欠点や長所は?
私たちが特定した長所：（適切な場合は暴言を吐いてください）
- 実装が簡単で、Cookie やヘッダーの追跡などは必要ありません。
- クライアント認証メカニズムに直交 - 認証が適切な場合、セッションを引き続き使用できる 2 番目のアプリに URL を簡単に渡すことができます (この場合の有効な使用例)
- このためだけに http を使用するため、安全である必要があります。
PHPSESSIDが言及されたので、私はこの他の質問に出くわしました.「URL内のセッション」アプローチは、セッション固定攻撃に対してより脆弱である可能性があると述べられています.
ただし、上記の 2 番目の箇条書きを参照してください: このセッションの概念と直交するように認証/承認を実装~指定する予定です。そのため、「セッション」URL を渡すことも機能になる可能性があるため、セッションをURL。