0

Safari 4.0.3 を実行している Mac OS X Leopard 10.5.8 を使用しています。私のクロス プラットフォーム Java アプリには、独自の内部 Web サーバーを備えた組み込みのネイティブ Web ブラウザーがあります。ブラウザーがクイックタイム (mov、mp4、m4v など) を必要とするファイルを提供しようとするたびに、ユーザー名とパスワードの資格情報ダイアログが表示されます。すべてのリクエストが通過して認証されるのを確認できます（少なくともhtmlファイルは認証されます）...次に、たとえばmp4のリクエストが表示され、認証されません。これはまるで、QuickTime が資格情報を渡さず、それ自体で認証を試みているかのようです。

これらの資格情報を自分で内部的に渡し、他のすべてのファイル タイプは基本認証で正常に動作します。QuickTime 7.6.4 とまったく同じファイルを使用して Windows でアプリを実行することもでき、期待どおりに再生されます (この場合、Windows は組み込みブラウザーとして IE8 を実行しています)。

QuickTime 7.6.4 と Safari 4 の基本認証に関する既知の問題はありますか? 運が悪かったので、少しオンラインで検索しました。

4

1 に答える 1

0

これは Safari 4 の問題ではなく、QuickTime 7.6.4 の問題です。このバージョンに追加された「セキュリティ」対策により、QuickTime 自体が認証されます。たとえば、ブラウザからサーバーへのhtmlファイルとmp4のリクエストは、私が提供する資格情報で満たされますが...資格情報の別のリクエストが後でQuickTimeによって生成されます。認証リスナーがブラウザーの一部であり、イベントが QuickTime から起動された状態で、これらの資格情報を入力することはできません。

この 2 番目の資格情報のセットに対する私の回避策は、要求ヘッダーの分析で見つかりました。QuickTime がアプリ内からリクエストを作成しているときに、GET ヘッダー内のファイルへのパスが相対パスであることがわかりました。これは、ベース パスが Web サーバーによって認識されているためです。[ファイル] メニューの [URL を開く] オプションを使用して QuickTime から同じ要求を行うと、ファイルへの絶対パス全体が GET ヘッダーに含まれていました。次に、この GET ヘッダーを確認できます。絶対パスがある場合、このリクエストは外部ソースからのものであり、資格情報が必要です。それ以外の場合は、アプリからのものであり、基本認証は必要ありません。

于 2009-11-03T15:20:03.333 に答える