1

いくつかのリソースを備えたサーバーがあります。これまで、これらすべてのリソースは人間のユーザーによってブラウザーを介して要求され、認証はユーザー名/パスワード方式で行われ、トークンを使用して Cookie が生成されました (セッションをしばらく開いておくため)。

現在、システムでは、他のサーバーがこのリソース サーバーに対して GET 要求を行う必要がありますが、取得するには認証が必要です。承認済み IP のリストを使用してきましたが、認証方法が 2 つあるとコードがより複雑になります。

私の質問は次のとおりです。

  • 同じコードを使用して人間のユーザーとサーバーを認証するための標準的な方法またはパターンはありますか?

  • そうでない場合、私が現在使用している方法は正しいものですか、それとも必要なことを達成するためのより良い/より標準的な方法はありますか?

ご提案いただきありがとうございます。

4

1 に答える 1

1

以前、Web サービスで基本認証と Cookie を組み合わせて使用​​したことがあります。基本認証では、次のような HTTP ヘッダーでエンコードされたユーザー名/パスワードを渡します。

Authorization: Basic QWxhZGluOnNlc2FtIG9wZW4=

「Basic」という単語の後の文字列は、コロンで区切られたエンコードされたユーザー名とパスワードです。REST API は、HTTP ヘッダーからこの情報を取得し、認証と承認を実行できます。認証に失敗した場合は HTTP Unauthorized エラーを返し、認証されているが承認されていない場合は HTTP Forbidden エラーを返し、認証と承認の失敗を区別します。それが Web クライアントであり、その人物が認証されている場合は、HTTP ヘッダーで次の内容をリクエストと共に渡します。

Authorization: Cookie

これにより、認証プロセスをやり直す代わりに、HTTP 要求から Cookie を取得し、それを承認に使用するよう Web サービスに指示します。

これにより、Web ブラウザーではないクライアントが同じ手法を使用できるようになります。クライアントは、すべての要求に対して常に基本認証を使用するか、最初の要求で基本認証を使用し、その後 Cookie を維持することができます。この手法は、個別のログイン ページがないシングル ページ アプリケーション (SPA)にも有効です。

注: ユーザー名とパスワードのエンコードは十分なセキュリティではありません。HTTPS/SSL を使用して通信チャネルを保護したい場合。

于 2012-11-19T16:42:13.533 に答える