11

私は標準の HTML ログイン ページを持っています。これは、ブラウザが提供する標準の HTTP 認証ポップアップよりもむしろ使用したいと考えています。現在、ログイン後のセッションを追跡するためにセッション Cookie を使用していますが、ステートレスで HTTP 認証を毎回通過させたいと考えています。私がヒットしている Web サービスは既にこれをサポートしているため、これはブラウザーのみの問題です。

jQuery で認証資格情報を追加するのは簡単ですが、それらを維持する方法がわかりません。ログイン ページ (JSP) からホームページ (別の JSP) に移動すると、明らかにログイン ページのユーザー名とパスワードのフィールドが保持されません。一部のブラウザーでは、ポップアップから入力した場合に HTTP 認証資格情報が保存されることはわかっていますが、XHRRequest を使用したときにそれらが保存されるかどうかはわかりません。もしそうなら、ブラウザ間でかなりの一貫性がありますか?

また、ユーザーはアプリケーションからも「サインアウト」できる必要があります。ブラウザが認証資格情報を保存している場合、JavaScript を使用してそれらをクリアする方法はありますか。

これを解決しようとする最初の人にはなれない気がします。いくつかのjQueryプラグインまたはすでにこれを処理しているものはありますか? それとも、私がやろうとしていることをすることは単に不可能ですか?

4

5 に答える 5

4

わかりました、私は助けに突き刺します...

まず、HTTP 認証がどのように機能するかを理解します。Basic と Digest の 2 つのバージョンがあります。Basic はプレーンテキストで送信し、ダイジェストは暗号化されます。これらのタイプの認証では、ユーザー名/パスワードがすべてのリクエストで HTTP ヘッダーに渡されます。ブラウザはログイン時にこれらをキャプチャし、アクセスできないブラウザ セッション Cookie に保存されます。この Cookie は、ブラウザ セッションが閉じられると削除されます。したがって、あなたの質問の 1 つに答えると、javascript からこれらにアクセスすることはできません。

ユーザー名とパスワード用に独自のセッション Cookie 変数を作成できます。このための jQuery 関数は非常に単純です。セッション Cookie を設定する方法の一例として、jquery-cookieモジュールを参照してください。これらはセッション cookie から取得され、各 ajax 要求と共に送信され、サーバーで検証されます。ただし、ネットワークをスニッフィングすると、誰でも簡単に認証の詳細を取得できるため、これは認証を行うのに特に適した方法ではありません。しかし、それはうまくいくでしょう。

これを行うには、セッション ID が要求ごとに送信されるセッション cookie ベースの認証を使用するのが最善の方法です。サーバー側では、すべての HTTP 要求に対して呼び出される関数が必要です。この関数は次のことを行う必要があります。

   check to see if the session has been authenticated
   if no:
       redirect to login screen
   if yes:
       do authorization and allow the user access to the page

ほとんどの Web フレームワークは、セッション Cookie 認証と、サーバーでのセッション ID の管理をサポートしています。これは間違いなく進むべき道です。

于 2012-02-14T10:36:52.787 に答える
4

次の 2 つのオプションがあります。

1) 資格情報のクライアント側ストレージ -- 良い考えではありません。明らかな理由から、ユーザー名/パスワードをクライアントに保存したくない場合があります。ハッシュ化されたバージョンのパスワードがあれば、それほど悪くはないかもしれませんが、それでもお勧めできません。いずれにせよ、クライアント側に保存する場合は、Cookie またはHTML5 ローカル ストレージ(まだ広くサポートされていません)を使用する必要があります。

2) 資格情報のサーバー側ストレージ -- 通常はセッションで行われます。次に、結果のセッション ID をクライアントに戻して、Cookie または後続の各 AJAX 呼び出しの URL に保持できます (?SESSID=xyzたとえば)。

サーバー側のアプローチは、最も安全で信頼性が高く、実装が最も簡単です。

于 2012-02-07T21:01:31.817 に答える
2

これは興味深いものです。

Cookie を使用してサーバー上のユーザー セッションを管理します。ユーザーが最初にログイン ページにアクセスしたときにセッションを作成し、応答を介してセッション ID/キーを値として Cookie の 1 つに渡します。ユーザーが認証されると、ユーザーの「キー」情報をCookieに入れ、「値」をサーバーのアプリケーションコンテキストに入れます。ユーザーがログに記録されると、以降のリクエストはサーバーのセッション Cookie 値に基づいて認証されます。承認は、Cookie 値として渡されたユーザーの「キー」に基づいて行われます。

ログアウト時にサーバーからセッション ベースの Cookie をクリアし、サイトをデフォルト ページに更新します。

Cookie はブラウザごとに異なります - 注意してください ;)

お役に立てれば。

于 2012-02-07T20:29:22.737 に答える
1

アップデート

以下の回答は2012年に投稿されたもので、リンクはほとんど死んでいます. しかし、それ以降、JSON Web Tokensを使用して、同じソリューションに対するより洗練された標準ベースのアプローチが登場しました。これは、それらの使用方法を説明する優れたブログ投稿です。

ほとんどの回答は、サーバー側のセッションを回避するという点を見逃しています。サーバーにアプリケーションの状態は必要ありません。最も近かった回答に報奨金を授与しますが、本当の功績は残りのディスカッション グループと正解のJon Mooreと、私が実際にそれを理解するのを手伝ってくれたMike Amundsenにあります。

私が得た最良の答えは Cookie を使用することですが、ほとんどのアプリケーション サーバーによって提供される典型的な自動セッション ID Cookie は使用しません。Cookie (後続の各リクエストで自動的に送信されます) は、サーバーによって署名されたユーザー識別子と時刻です。Cookie に有効期限を含めることができるため、サーバー上で典型的な 30 分間のセッションをシミュレートし (つまり、後続の要求でプッシュする必要があります)、同じ Cookie が永久に有効になるのを防ぐことができます。

XHR/AJAX 部分はニシンです。これは、XHR リクエストを実行している場合でも、昔ながらのページごとの Web アプリケーションを実行している場合でも機能します。主なポイントは次のとおりです。

  • Cookie は後続のリクエストで自動的に送信されるため、特別なスクリプトは必要ありません。ブラウザーが既に機能しているだけです。
  • サーバーはユーザーのセッションを保存する必要がないため、ユーザーはクラスター内の任意のサーバーにアクセスでき、再認証する必要はありません。
于 2012-02-14T16:54:35.403 に答える
0

authent の一部をクライアントにプッシュすることを検討しているという点で、少し興味深いです。従来のソリューションが必要な場合は、KOGI のサーバー側の提案が最適です。

しかし、ユーザーが提供したシークレットに関連するメモリ リークについても質問しているようです。良い質問です。しかし、一般的に答えるには、ブラウザ固有である必要があると思います。クライアント側のアプリケーション (つまり、ブラウザー、またはブラウザーの js) がユーザー入力値を保存する場所は、ブラウザーの内部、JavaScript エンジンの内部に依存します。

ほとんどの場合、これらの値はメモリ全体で不必要に複製されることはありませんが、それを保証する方法はありません。責任ある JavaScript コーディングの実践以外に、ユーザー入力の場所の制限を保証するためにできることは何もありません。

少し余談

基本的なポイントは、それをクライアントに保存する場合、実際には安全ではないということです。サーバーが暗号化された情報を、サーバー (または正しい資格情報を介したユーザー) のみが持つキーを使用してクライアントに保存しない限り。したがって、JS アプリケーションをコーディングして、クライアントで何らかの認証を行うことができます。これは、銀行カード (以前は?) が PIN をカードの PIN にチェックし、DB に戻るのではなく POS 認証を行う方法とほぼ同じです。これは、ユーザーがクライアントの「ダークエリア」クッキー/ローカルストレージ/銀行カードの磁気テープに直接読み取り/書き込みアクセスできないという (やや薄っぺらな) 仮定に基づいています。したがって、これは、資格情報の唯一の修飾子としてではなく、偽の認証者の失格としてのみアドバイスします。

主なポイント

ステートレスにしたい場合は、ユーザー資格情報をローカル ストレージに保存するか、Cookie として保存し、サーバー キーで暗号化します。暗号化された/保存された資格情報を含む XHR を HTTPS 経由でサーバーに送信する必要がある場合は、サーバーで暗号化を解除してコールバックに送信します。次に、HTTPS のクリアテキストを渡して認証を行います。

于 2012-02-14T15:57:14.790 に答える