2012-01-17 11 views
1

これは私が逃した繰り返しであるならば、私の謝罪ので、私は、(ここではGoogleやのいずれか)私の質問に正確な答えを見つけることができませんでした:XML-RPC認証

私が書いています特定の仕様に準拠する必要があるJavaのApacheのXML-RPCライブラリ(これは少し後悔しています)を使用しているXML-RPCサーバーです。認証では、サーバーはorg.apache.xmlrpc.common.XmlRpcNotAuthorizedExceptionを生成します。これは、必要とされる動作ではありません。私はHTTPエラー401(認証されていない)と403(禁止されている)を返したいと思います。しかし、Apacheはこれらの例外を投げつけ続け、私はその周りに道を見つけることができません。例えば、応答のために

が正しいユーザ名/パスワードの送信後に受信:

HTTP/1.1 200 OK 
Content-Length:362 
Content-Type:text/xml 
Server:Jetty(7.x.y-SNAPSHOT) 

<?xml version="1.0" encoding="UTF-8"?> 
<methodResponse> 
    ...correct response information here 
</methodResponse> 

を...と、間違ったユーザー名とパスワード:

HTTP/1.1 200 OK 
Content-Length:252 
Content-Type:text/xml 
Server:Jetty(7.x.y-SNAPSHOT) 

<?xml version="1.0" encoding="UTF-8"?> 
<methodResponse> 
    ...xmlrpc exception here 
<methodResponse> 

は私が望んでいない "HTTP/1.1 200 OK"私は "HTTP/1.1 401 Unauthorized"を希望します

私はApacheのReflectiveXmlRpcHandler(または類似のもの)を継承し、例外を傍受しようと考えていましたが、この問題の良いアイデアを見つけました。

アイデア?

答えて

2

これは難しいようです。 XML-RPC Specification

Response format 

Unless there's a lower-level error, always return 200 OK. 

悪い認証資格で述べたように、低レベルのエラーではない、それだけで特定のユースケースです。 しかし、この特定のケースを処理するためにクライアント側で例外を有効にすることができます(セキュリティ上の問題に注意してください)

+0

ありがとうございます...私は最後の数日間同じ結論に達しました。これをHTTPサーバー(私の場合はJetty)で処理するとどう思いますか?それがXML-RPCライブラリに渡される前に認証を処理しますか?すなわちフェイル・ファースト? –

+0

あなたはどのような認証の王様を提供していますか? HTTP経由の基本? – Grooveek

+0

はい、基本的なHTTP認証です。 –

1

私はコードを投稿しますが、あまりにも多くの場所に触れていました。エッセイ...私が何をしたか

RuntimeExceptionを拡張PropagatedHttpExceptionを作成し

  • 。それはちょうど1つのフィールド、コード、HTTPエラーコードです。
  • XmlRpcServletServerを拡張:
    • オーバーライドwriteErrorをエラーがPropagatedHttpExceptionであり、それがある場合、 投げるが、それはすぐにバックアウトかどうかを確認します。
    • オーバーライド PropagatedHttpExceptionをキャッチし、適切なHTTPエラーとして渡す(HttpServletRequestHttpServletResponse)をオーバーライドします。
  • XmlRpcServletを拡張: 特定のHTTPエラーコードのPropagatedHttpExceptionをスローカスタムAuthenticationHandlerを設定
    • 我々はすでに私たちは、これがどのように動作するかを理解し始めたときにカスタム認証ハンドラを持っていたが、あなたの場合、多分それが必要とされていないとwriteErrorコードでカスタムXmlRpcServletServer.

を返すためにオーバーライドnewXmlRpcServer XmlRpcNotAuthorizedExceptionをチェックするように調整することができます。実際に私はこの例外が今日まで存在していなかった...

クライアント側からは、Apache XML-RPCは戻ってきたエラーコードをチェックせず、解析しようとしますその結果に関係なくXML応答。

NTLMのようなものが動作するように、認証がJREの組み込みの認証に引き込まれるようにするためGrooveekの答えは非常に気になりませんが、HTTP 200を返すならこれはこれまで不可能です仕様を破ることなく動作します。

+0

私が本質的にしたことは、Apacheで発生するすべての認証を放棄することでした。 WebサーバーとしてJettyを使用し、XML-RPCの部分に進む前に呼び出しを傍受しました。これは魅力として機能し、実際にはより速い応答にもなりました(受け入れられた回答を参照)。あなたの経験を共有してくれてありがとう! (+1) –

+0

ええ、私たちの場合でも、異なるXML-RPCオブジェクトは異なるアクセスレベルを持っています。だから当分の間残念ながら私たちは水の中で死んでいる... – Trejkaz

+0

@Trejkaz主にIDのための資格情報ではない、そしてアプリケーションは承認を決定する? Authozationは、データトランザクションチャネルではなく、帯域外(ローカルに格納またはリモート)である必要があります。 – Dennis