1

（注：私は最終的にこれを自分で解決し、なりすましは主な問題ではないことが判明しました。ただし、なりすましが発生する理由を誰かが知っている場合は、お知らせください。）

Silverlight アプリケーションから呼び出されている WCF サービスがあります (これらは同じ Web アプリケーションによってホストされています)。サービスの呼び出しは、操作自体にかかる時間に比べて驚くほど遅いです。WCF トレース ログを見ると、偽装に 2 秒以上かかっているように見えます (5 行目を参照)。

[15:32:3.193] From: Processing message 1.
[15:32:3.193] Activity boundary.
[15:32:3.193] Received a message over a channel.
[15:32:3.194] ServiceChannel information.
[15:32:5.539] Security Impersonation succeeded at the server.
[15:32:5.540] To: Execute 'MyNamespace.GetFloorplan'.
[15:32:5.540] Activity boundary.
[15:32:6.302] From: Execute 'MyNamespace.GetFloorplan'.
[15:32:6.302] Activity boundary.
[15:32:6.305] Sent a message over a channel.
[15:32:6.306] Activity boundary.

偽装は、構成で明示的に有効にする (またはコードからトリガーする) 必要があると思っていたので、これは私を困惑させます。私はコンサルタントとしてこのプロジェクトに参加したばかりなので、ソース コード全体の概要をまだ把握していませんが、「なりすまし」または「なりすまし」というテキストはソース コードのどこにも存在しません。混乱に加えてSystem.Threading.Thread.CurrentPrincipal.Identity、サービス内から名前のない認証されていない ID が返され、 がSystem.Security.Principal.WindowsIdentity.GetCurrent().Name返さIIS APPPOOL\MyCustomAppPoolれるため、なりすましは実際には何も達成していないようです。

フォーム認証と ASP.NET 互換モードを使用します。後者を無効にすると (私がまだ知らないそれに依存する機能がある可能性があるため、永続的に実行できるかどうかはわかりません)、Security Impersonation succeeded at the serverログから消えますが、 と の時間差はまだほとんどありませReceived a message over a channel.んTo: Execute 'MyNamespace.GetFloorplan'.二秒。操作に追加[OperationBehavior(Impersonation = ImpersonationOption.NotAllowed)]しても役に立ちません。

誰かがここで何が起こっているのか理解していますか? (私の目標は、なりすましや、余分な 2 秒を占めるものを取り除くことです。)

サービス クラスには次の属性があります (理想的にはインターフェイスに配置する必要があることはわかっていますが、最初にサービスに配置された理由があるかどうかはまだわかっていません)。

[ServiceContract(Namespace = "")]
[SilverlightFaultBehavior]
[AspNetCompatibilityRequirements(RequirementsMode = 
                                 AspNetCompatibilityRequirementsMode.Allowed)]

サービス構成は次のとおりです。

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" 
                             multipleSiteBindingsEnabled="true" />
  <behaviors>
    <serviceBehaviors>
      <behavior name="">
        <serviceMetadata httpGetEnabled="true" />
        <serviceDebug includeExceptionDetailInFaults="false" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
  <bindings>
    <customBinding>
      <binding name="SilverlightServiceBinding">
        <binaryMessageEncoding />
        <httpTransport />
      </binding>
    </customBinding>
  </bindings>
  <services>
    <service name="MyNamespace.FloorplanService">
      <endpoint address="" binding="customBinding" 
                bindingConfiguration="SilverlightServiceBinding" 
                contract="MyNamespace.FloorplanService" />
      <endpoint address="mex" binding="mexHttpBinding" 
                contract="IMetadataExchange" />
    </service>
  </services>
</system.serviceModel>

クライアント構成:

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding name="BasicHttpBinding_FloorplanService" 
               maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
        <security mode="None" />
      </binding>
    </basicHttpBinding>
  </bindings>
  <client>
    <endpoint address="../Floorplan/FloorplanService.svc"
              binding="basicHttpBinding" 
              bindingConfiguration="BasicHttpBinding_FloorplanService"
              contract="FloorplanServiceProxy.FloorplanService" 
              name="BasicHttpBinding_FloorplanService" />
  </client>
</system.serviceModel>
4

2 に答える 2

2

なりすましメッセージはおせっかいであることが判明しました (ASP.NET 互換モードを無効にするとメッセージが表示されなくなったので、理解する必要がありましたが、要求にはまだほとんど時間がかかりました)。ただし、WCF トレース ログは正しい方向を示してくれました。操作が実際に呼び出される前に、WCF で非常に時間がかかることが明らかに発生していました。最終的に、Web アプリケーションにユーザー認証/認可クラスが含まれていることがわかりました。これは、不適切に構成された依存性注入コンテナーが原因で、要求ごとに数回呼び出され、多くの不要なデータベース要求が発生していました。

教訓 (他の人が同じ問題に出くわした場合): 構成によっては、WCF がコードの実行前に認証および承認メカニズムを呼び出す場合があり、これらに無視できない時間がかかる場合があります。

于 2012-11-02T17:27:21.777 に答える
0

Web サイトの IIS 認証設定である可能性があります。

複数の認証タイプを有効にしていて、他の認証タイプのいずれかを最初に試行している場合。

于 2012-11-02T15:55:12.693 に答える