Błąd bezpieczeństwa WCF + SSL Silverlighta - crossdomain.xml nigdy nie był wymagany

Question

(Widzę kilka pytań dotyczących mojego problemu, ale żadne z rozwiązań nie działa dla mnie, ponieważ napotykam ten problem w produkcji, a nie podczas lokalnego rozwoju, i mam próbowałem już wszystkich proponowanych poprawek.)

Mam aplikację Silverlight 4, która korzysta z usług WCF hostowanych przez IIS. W produkcji te usługi są dostępne przez HTTPS. Pomimo a valid crossdomain.xml plik wciąż otrzymuję błąd słynny „bezpieczeństwo” podczas korzystania z usługi:

An error occurred while trying to make a request to URI 'https://MYDOMAIN/MYSERVICE.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details. ---> System.Security.SecurityException ---> System.Security.SecurityException: Security error...

Korzystanie Skrzypek widzę, że nie został złożony wniosek do crossdomain.xml lub clientaccesspolicy.xml. Istnieje żądanie CONNECT do serwera, ale to wszystko.

Przeczytałem, że ten błąd, chociaż wskazuje na problem z plikiem crossdomain.xml/clientaccesspolicy.xml, może również zostać zgłoszony, gdy serwer wyda niepoprawny certyfikat. Nie wydaje mi się, że tak jest w moim scenariuszu.

Jestem pewien, że jest poprawnie skonfigurowane następujące:
1. crossdomain.xml jest ważna i gościł w głównym miejscu
2. Służby działają (Mamy innych klientów w różnych technologiach, które z nich korzystają , w tym Adobe Flex, który opiera się na crossdomain.xml.)
3. Aplikacja Silverlight działa (działa dobrze z lokalnymi usługami i usługami na udostępnionym serwerze programistycznym ***)
4. Aplikacja Silverlight nawet nie działa spróbuj zażądać pliku crossdomain.xml lub clientaccesspolicy.xml (potwierdzonego przez Fiddler)
5. Aplikacja Silverlight używa właściwej konfiguracji do uzyskiwania dostępu do WCF przez https. Poniżej znajduje się konfiguracja:

<configuration> 
    <system.serviceModel> 
     <bindings> 
      <basicHttpBinding> 
       <binding name="BasicHttpBinding_IMyServices" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647"> 
        <security mode="Transport" /> 
       </binding> 
       </basicHttpBinding> 
     </bindings> 
     <client> 
      <endpoint address="https://MYDOMAIN/MYSERVICE.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IMyServices" contract="Services.IMyServices" name="BasicHttpBinding_IMyServices" /> 
     </client> 
    </system.serviceModel> 
</configuration> 

Co jeszcze może powodować tego rodzaju problemy? Czy to możliwe, ponieważ serwery WWW są zrównoważone? Czy jest jakiś problem z certyfikatem, którego nie zauważyłem? Jeśli potrafisz przynajmniej wskazać mi właściwy kierunek, który byłby bardzo cenny.

(*** Warto podkreślić: Z podobnym problemem spotkało nas środowisko programistyczne. Aplikacja Silverlight nie mogła uzyskać dostępu do usług WCF na współużytkowanym serwerze programistycznym, mimo że ma poprawny plik crossdomain.xml i nie korzysta z HTTPS Pracowałem nad tym, dodając serwer programistyczny jako zaufaną stronę w IE, jednak to samo obejście nie działa w przypadku produkcji, a nawet wtedy nie byłoby to akceptowalne, ale fakt, że musiałem to zrobić w środowisko programistyczne sprawia, że ​​martwię się, że coś przeoczyłem po drodze ...)

Answer 1

Problem polegał na tym, że zaginęłem clientaccesspolicy.xml. Posiadanie crossdomain.xml nie było w tym przypadku wystarczające. I think jest to spowodowane tym, że wywołanie WCF nie było tylko przeglądarką, ale także krzyżowym (aplikacja Silverlight była obsługiwana przez http, ale usługi były obsługiwane przez https).

Ponadto moja clientaccesspolicy.xml musiał wyraźnie zezwolić na dostęp do http następująco:

<?xml version="1.0" encoding="utf-8"?> 
<access-policy> 
    <cross-domain-access> 
     <policy> 
      <allow-from http-request-headers="SOAPAction"> 
       <!-- IMPORTANT! Include these lines --> 
       <domain uri="http://*"/> 
       <domain uri="https://*"/> 
      </allow-from> 
      <grant-to> 
       <resource path="/" include-subpaths="true"/> 
      </grant-to> 
     </policy> 
    </cross-domain-access> 
</access-policy> 

Teraz działa jak czar.

Kilka rzeczy, które mnie poturbowały:
* Moja przeglądarka buforowała pliki clientaccesspolicy.xml i crossdomain.xml.Musiałbym wyczyścić pamięć podręczną za każdym razem, gdy zmieniłem jeden z tych plików lub nie rozpoznałbym nowszej wersji, pomimo tego, że usługi IIS zostały skonfigurowane tak, aby uniemożliwić buforowanie klienta tego pliku.
* Żądania dotyczące pliku clientaccesspolicy.xml i crossdomain.xml nie zawsze pojawiały się w skrzypce. Często widziałem zamiast tego żądania CONNECT. Nie rozumiem powodu tego, ale nauczyłem się nie polegać na skrzypcach, aby potwierdzić, że te wnioski są składane. Być może mam gdzieś jakieś zbędne ustawienie (i nie jest to ustawienie "Odszyfruj ruch HTTPS", które już wyłączyłem).

Answer 2

Mam ten sam błąd, gdy próbuję wykonać połączenie z moją witryną za pośrednictwem protokołu http, a moja usługa została przekroczona przez https. Ten błąd wystąpił, ponieważ mój ISS ​​nie miał certyfikatu, więc gdy aplikacja próbowała pobrać polisę klienta, nie udało się.

Spójrz na każde narzędzie do debugowania w przeglądarce i poszukaj pliku clientacccesspolicy, a następnie sprawdź, czy jest pobierany.