2014-07-10 9 views
5

SytuacjaZintegrowany potok WCF, WebAPI i OWIN IIS. Przejdź OWIN oparty na trasie

Mam aplikacji Silverlight, który używa WCF backend. Idąc dalej przenieśliśmy się do klientów JS z WebAPI.

Mam kilka kontrolerów WebAPI, których chciałbym użyć z klienta Silverlight, a więc mam je załadowane w aplikacji ASP.Net, która obsługuje usługi WCF.

To działa dobrze od punktu widzenia "wszystkie usługi są dostępne", jednak autoryzacja jest wywoływana wiele razy dla wywołań WCF; z OWIN i przez WCF ServiceAuthorizationManager

Po stronie WCF moja implementacja ServiceAuthorizationManager sprawdza token w AuthHeader, a następnie transformuje token (w Sensus Transformation ClaimsModel System.Identyfikator). Po stronie WebAPI używam Thinktecture.IdentityModel, która zapewnia OWIN Middleware do sprawdzania poprawności tokena i przekształcania roszczeń.

Problem polega na wywołaniu oprogramowania pośredniego OWIN dla wszystkich żądań (w tym żądań WCF). Tak więc w przypadku żądania WCF otrzymuję dwa razy poprawność i transformację. Nie mogę po prostu usunąć ServiceAuthorizationManager i pozwolić oprogramowaniu pośredniczącemu go obsłużyć, ponieważ WCF nic nie wie o OWIN, a ostatnim krokiem ServiceAuthorizationManager jest ustawienie głównego kontekstu operacji (innego niż ClaimsPrincipal.Current).

Pytanie

Czy ktoś miał problem jak to wcześniej z WCF i WebAPI siedzi obok siebie? Czy najlepszym wyjściem jest jak najszybsze wyjście z rurociągu OWIN w przypadku wywołań WCF, a jeśli tak, to w jaki sposób można to zrobić za pomocą otwartej metody koordynacji? Czy mogę w jakiś sposób użyć metody IAppBuilder.Map, aby rejestrować tylko komponenty do sprawdzania poprawności i transformacji znaczników dla tras API (w tym przypadku cokolwiek zaczynającego/api)?

Odpowiedz

2

Udało mi się uruchomić to za pomocą Branched Pipeline.

app.MapWhen(c => c.Request.Path.Value.Contains("/api"), 
        subApp => 
        { 
         subApp.UseJsonWebToken(
          issuer: clientDetails.Issuer, 
          audience: clientDetails.Audience, 
          signingKey: clientDetails.SigningKey); 

         subApp.UseClaimsTransformation(transformer.Transform); 

         var webApiConfig = WebApiConfig.Configure(); 
         webApiConfig.DependencyResolver = StructureMapConfig.HttpDependencyResolver(); 
         subApp.UseWebApi(webApiConfig); 
        }); 

Jedyną rzeczą Zastanawiam się dlaczego IAppBuilder.MapWhen jak powyższe prace, ale kiedy używam IAppBuilder.Map nie wydają się działać ...

app.Map("/api", 
     subApp => ... 
+0

Jeśli ktoś może wyjaśnić, dlaczego wersja 'app.Mapp' nie działa, byłoby to bardzo cenne? –

+0

Mam ten sam problem: MapKiedy z jawnym zgodnym predykatem działa, a Map nie. –

0

Wielkie dzięki dla odpowiedzi powyżej. Dzięki temu kawałkowi kodu mogłem dowiedzieć się, jak warunkowo kierować połączenia, aby połączenia WCF nie były przechwytywane przez oprogramowanie warstwy statycznej.

//app.UseMiddleware<ServeStaticFilesMiddleware>(); 

    app.MapWhen(c => !c.Request.Path.Value.Contains(".svc"), 
      subApp => 
      { 
       subApp.UseMiddleware<ServeStaticFilesMiddleware>(); 
      });