0

IIS Expressで実行されているWebアプリケーションからイントラネットWebサービスに接続しようとすると、そのWebサービスは403Forbiddenを返します。単体テストを介して、またはCassiniまたはサーバー上のIIS 7.5で実行されている同じサイトからアクセスすると、サービスは正しく機能します。私の腸はこれが構成の問題であると私に言います、しかし私はどこから探し始めるべきかわかりません。

IIS Expressで実行されているサイトからリモートWebサービスにアクセスしたときに、リモートWebサービスが403 Forbiddenを返す原因は何ですか？

アクセスしているサービスを明確にするために、SOAPベースではありません。特定のネットワーククレデンシャルを設定し、以下のコードが示すリクエストと一緒に渡します。

protected XDocument Search(Uri requestUri)
{
    var nc = new NetworkCredential(this.config.ServiceUserName,
        this.config.ServicePassword);
    var cCache = new CredentialCache();
    cCache.Add(requestUri, "Basic", nc);

    var request = (HttpWebRequest)HttpWebRequest.Create(requestUri);
    request.Credentials = cCache;
    request.PreAuthenticate = true;
    request.Method = WebRequestMethods.Http.Get;

    var response = (HttpWebResponse)request.GetResponse();
    return XDocument.Load(new StreamReader(response.GetResponseStream()));
}
4

2 に答える 2

0

Web サービス側の Windows 認証の場合に発生する/発生する問題のリスト:

  • Cheeso が指摘したように、リクエストは単に匿名 (またはローカル) アカウントで実行されている可能性があります。これは、呼び出し元ユーザーの偽装なしで実行し、プロセス自体が間違ったアカウントで実行されているか、ユーザーが匿名であると見なされ、要求がその特別なローカル「匿名」アカウントに切り替えられていることが原因である可能性があります。
  • 着信ユーザーの偽装をオンにして上記を修正すると、「NTLM ワンホップ地獄」の問題が発生します。着信資格情報は他のサーバーで使用できません (Kerberos は解決策ですが、ほとんどの場合利用できる可能性は低いです)。
  • 偽装を無効にする (または、着信ユーザーのアカウントではなくプロセスのアカウントでコードを実行する) ことによって最初の問題を修正し、プロセスをドメイン アカウント (または実際に Web サービスへのアクセス許可を持つ他のアカウント) で実行するようにすると、事実に遭遇します。ユーザーがアクセスしてはならないデータを取得する可能性を開いている可能性があります。

基本的に、どのアカウントが Web サービスにアクセスできるか、またはアクセスする必要があるかを把握し、そのアカウントで Web サービスにアクセスするコードを実行する必要があります。アカウントはローカルでログインする必要があります (着信ユーザーの ID は使用できません)。

于 2012-06-16T04:26:54.610 に答える
0

今はその理由を掘り下げる時間はありませんが、プロキシ設定に関係があると言えます。ボックスの別のプロキシ プロバイダーに切り替えると、問題が軽減されました。この内部トランザクションはプロキシをすべてバイパスする必要があり、IIS が他のメカニズムと異なる動作をする理由はわかりません。残念ながら、これを回答としてマークし、プロキシ設定を確認するための小さな通知が誰かに役立つことを願っています. 申し訳ありませんが、これはより具体的ではありません。

于 2012-06-18T19:20:05.573 に答える