JettyにSecurityを。DIGEST認証(続き)
昨日の続き。
ドエライ事態に陥りました。
環境から言うと、
Windows7、FlashBuilder4.6で、AIR開発(FlexSDK4.6)
同PCで、FlashBuilder4.6でScalaプロジェクトでJetty起動、デバッグしています。
ここで問題になったのが、
JettyにDIGEST認証設定して、AIR側で、
URLRequestDefaults.setLoginCredentialsForHost("localhost","user","pass");
を実装します。
認証を通る事は出来ますが、この後、AIRからJettyの特定のディレクトリのXMLを
URLLoaderを使って、取得しています。
この瞬間、そのXML、Javaが掴んで離さないです。
ファイルの削除が失敗するので、気づいたのですが、
エクスプローラーから直にファイル削除しようとすると、
「Java(TM) Platform SE binalyによって、ファイルが開かれている為、操作を完了出来ません」
とエラーが出ます。
File.delete()は、失敗しても何故かExceptionが発生せず、
FileUtils.forceDelete()を実行すると、IOExceptionが発生します。
単純な疑問として
URLLoader使って、ロードしただけなのになぜJavaがファイルを掴む?
同一PCだから、何かあるのかと思い、
Jettyを別PCに入れて、URLLoaderして見ましたが、結果同じでした。
DIGEST認証だから、何かあるのかと思い
BASIC認証に変えて、URLLoaderして見ましたが、結果同じでした。
ワカラーン
URLRequestDefaultsが何かあるのかと思い、
URLRequestに個別にヘッダーを設定してみたら、結果変わりました。
var auth:String = "user" + ":" + "pass"; var encoder:Base64Encoder = new Base64Encoder(); encoder.encode(auth); var header:URLRequestHeader = new URLRequestHeader("Authorization", 'Basic ' + encoder.toString()); request.requestHeaders.push(header);
どういうことだ・・・。
素人考えですが、Javaがファイルを掴むということは、Jettyが悪い?
でも、Requestの方法変えると、大丈夫・・・。
ちなみに、ブラウザで認証して、ブラウザでXMLを表示すると、ファイル掴まない。
ということは、URLRequestDefaultsが悪い?
それとも私が悪い?
直感であれですが、URLRequestDefaultsなんとなく怪しい気がする・・・。
ちょっと風にあたってこよう。
追記)
罠がまってました。AIRが原因ではありません。
http://d.hatena.ne.jp/nosa1/20120214/1329182933