問題タブ [digest-authentication]

ドメインの/adminで非常に基本的なダイジェスト認証を設定しようとしています（実際には、サブドメインです）。私は自分の：に認証手順を登録しbootstrap.phpます

次に、プラグインを使用してすべてのリクエストにログインするようにユーザーにリクエストしますAdminAuth.php。

これはうまくいくようです。ただし、認証は常に失敗します。クライアントとサーバーの両方のMD5ハッシュを何度もチェックしましたが、それらは正しいです。admins.txtは次のようになります。

また、ダイジェストを基本認証に変更し、MD5ハッシュをプレーンテキストに変更しようとしました。ただし、認証は引き続き失敗します。

コンソールで次のコマンドを実行すると、次のようになります。

次の出力が得られます。

特に注意してくださいAuthentication problem. Ignoring this.誰かが何がうまくいかない可能性があるかについての手がかりを持っていますか？提供されたユーザー資格情報が正しいことを100％確信しています（大文字などもチェックしました）。

JMeterを使用してWebアプリケーションをテストしようとしていますが、ダイジェスト認証を使用するように設定する方法に関するドキュメントがありません。プロキシサーバーを使用して認証を記録しようとしましたが、リクエストにUIに表示される情報がなく、再生が機能しません。JMeterのデフォルトは基本認証のようですが、ダイジェストを使用できるというヒントを聞いたことがあります。簡単な例がいいでしょう。

Apache Sling でダイジェスト認証は可能ですか? もしそうなら、どんな指針も感謝します！

Rails で HTTP ダイジェスト認証をテストする方法を知っている人はいますか?

http://lightyearsoftware.com/2009/04/testing-http-digest-authentication-in-rails/にある例では、「NameError: uninitialized constant ActionController::ProcessWithTest」を取得しています

ダイジェスト認証を使用してWebサーバー（Apache 2.2.17）と通信しようとし、POSTメソッドを使用してデータを送信しようとすると、問題が発生します。常に401エラーが返されます。ただし、データを投稿しない場合、またはFiddlerが実行されている場合（データを投稿する場合でも）はうまく機能します...問題の原因について考えていますか？

ダイジェストアクセス認証を正しく実行するためのクロスプラットフォームソリューションが必要です。できれば、POST要求に「qop=auth-int」を使用します。Operaだけがqop=auth-intで応答するようで、IE6はダイジェストで問題が発生します。

だから私は自分自身に思いました：私はAJAXリクエストを実行し、setRequestHeader（）を使用して自分で認証を実装します。RFC-2617を実行するために必要なサーバー側のものをすでに実装しているので、ここでの唯一の主要なハードルは、401 WWW-Authenticateヘッダーを解析して適切な応答を形成するために、JavaScriptを介して十分な制御を取得する方法を見つけることです。

問題は次のとおりです。ブラウザが401をXMLHttpRequest.onreadystatechangeに渡すのではなく、処理しているようです。ユーザー/パスがサイトにすでに保存されている場合、ChromeとFirefoxは認証ヘッダーのタックをサイレントに処理します。そうでない場合は、通常のログインボックスが表示されます。

Digest Authの不備について警告し、TLSを使用する必要があると言う前に、セキュリティ上のリスクを認識しています。サーバーは非常にリソースが制限された組み込みプラットフォームであり、SSLは実際にはオプションではありません。サーバーは、パブリックインターネットに表示されるようにインデントされていません。したがって、認証は、MitMの実行方法を知っている悪意のある攻撃者ではなく、好奇心の強い無許可の人々が変更を加えることを思いとどまらせるためのものです（マネージャーは善意であるが知識が不十分であると考えてください）。

http.getを使用するときにダイジェスト要求を実装しようとすると、毎回「ダイジェスト認証に失敗しました」というメッセージが表示されます:(

このコードの何が問題になっていますか？

基本認証を設定するプロジェクトを開始しました。ダイジェスト認証に切り替えたいと思います。問題は、実際のパスワードではなく、実際のパスワードのハッシュを提供した場合にのみ認証が検証されることです。

BASICからDIGESTに切り替えるために、次のことを行いました。

1. 私のweb.xmlでauth-methodをDIGESTに変更しました

2. JDBCレルムのJAASコンテキストを「jdbcDigestRealm」に変更しました

3. 私のデータベースでは、以前はパスワードとして「password」を使用していましたが、MD5（webuser：postgres：webuser）（webuserはログイン、webuserはパスワード、postgresはレルム）の結果に変更しました。つまり、テーブルのパスワードをc3c2681ed07a5a2a5cb772061a8385e8に設定しました。

私が抱えている問題は、リソースにアクセスしようとするとブラウザにログインポップアップが表示されるのに、パスワードとして「webuser」を使用しても機能しないことです。ただし、パスワードとして「c3c2681ed07a5a2a5cb772061a8385e8」を使用すると機能します。まだBASIC認証モードになっているようです。

どんな手掛かり ？

ありがとうございました ！

これは非常に広範な質問であることは承知していますが、完全な実装について質問するつもりはありません (それを実行してくれるライブラリがあることは知っています)。それについていくつかの小さな質問があります。

1. nonce 値は http ヘッダーに入るべきですか?
2. クライアント側で http ヘッダーからノンスを読み取るにはどうすればよいですか?
3. nonce をサーバーに送り返すにはどうすればよいですか? もしかして隠しフィールド？または、ブラウザは後続のリクエストごとにそれを行いますか?
4. クライアントナンス (cnonce) に関しては、他のフィールドや非表示フィールドと同じ方法で送信する必要がありますか?
5. サーバーから cnonce を取得するにはどうすればよいですか? ノンスと同じ？

私のプロジェクトでは、サーブレットを使用して html ページを生成しており、http ログイン フォームを処理するサーブレットがあります。