7

(Vedo diverse domande relative al mio problema ma nessuna delle soluzioni funziona per me poiché sto incontrando questo problema nella produzione, non durante lo sviluppo locale, e ho già provato tutte le correzioni proposte.)Silverlight WCF + Errore di sicurezza SSL - crossdomain.xml mai richiesto

Ho un'applicazione Silverlight 4 che utilizza i servizi WCF ospitati da IIS. Nella produzione questi servizi sono accessibili tramite HTTPS. Pur avendo a valid crossdomain.xml file ancora ottenere il famoso "Errore di protezione" quando si accede al servizio:

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...

Utilizzando Fiddler posso vedere che nessuna richiesta è fatta per crossdomain.xml o clientaccesspolicy.xml. C'è una richiesta CONNECT al server ma questo è tutto.

Ho letto che questo errore, sebbene indichi un problema con crossdomain.xml/clientaccesspolicy.xml, può anche essere generato quando il server emette un certificato non valido. Questo non sembra essere il caso nel mio scenario.

sono certo il seguente è corretta:
1. crossdomain.xml è valido e ospitato nella root del sito
2. I servizi funzionano (Abbiamo altri clienti in varie tecnologie che li utilizzano , tra cui Adobe Flex che si basa su crossdomain.xml.)
3. L'app Silverlight funziona (Funziona perfettamente con servizi e servizi locali su un server di sviluppo condiviso ***)
4. L'app Silverlight non funziona nemmeno prova a richiedere crossdomain.xml o clientaccesspolicy.xml (come confermato da Fiddler)
5. L'app Silverlight utilizza la configurazione corretta per accedere a WCF tramite https. Di seguito la configurazione:

<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> 

Cos'altro può causare questo tipo di problema? Potrebbe essere perché i server web sono bilanciati dal carico? O c'è un problema con il certificato che non ho notato? Se puoi almeno indicarmi la giusta direzione che sarebbe molto apprezzata.

(*** Qualcosa pena sottolineare:. Mi sono imbattuto in un problema simile nel nostro ambiente di sviluppo L'applicazione Silverlight è stato in grado di accedere ai servizi WCF su un server di sviluppo condiviso, pur avendo un crossdomain.xml corretta e non tramite HTTPS Ho lavorato attorno ad esso aggiungendo il server di sviluppo come sito attendibile in IE, tuttavia questa stessa soluzione non funziona per la produzione, e anche in questo caso non sarebbe una soluzione accettabile, ma il fatto che dovessi farlo nel l'ambiente di sviluppo mi preoccupa di aver perso qualcosa lungo la strada ...)

+0

Qual è il codice di risposta per la richiesta di connessione al server? Quando accedo al link che hai fornito nel mio browser, ricevo la risposta "403 - Vietato: accesso negato" – wickedtreemonkey

+0

Ricevo un codice di risposta di 200. Questo link restituisce un 403 perché sto collegando alla radice del dominio che è limitato. Gli endpoint del servizio, a cui non voglio collegarmi, sono accessibili al pubblico e pertanto restituiscono una risposta di 200. – Keith

+0

visite http://stackoverflow.com/questions/7847220/clientaccesspolicy-xml-not-requested-the-first alcuni browser--time-in-. questo forse utile. –

risposta

10

Il problema era che mi mancava clientaccesspolicy.xml. Avere crossdomain.xml non era sufficiente in questo caso. I penso che sia dovuto al fatto che la chiamata WCF non era solo cross-browser ma anche cross-protocol (l'app Silverlight era servita via http ma i servizi erano serviti tramite https).

Inoltre, il mio clientaccesspolicy.xml doveva consentire esplicitamente l'accesso a http come segue:

<?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> 

Ora funziona come un fascino.

Un paio di cose che mi hanno scattato lungo la strada:
* Il mio browser è stato caching clientaccesspolicy.xml e crossdomain.xml.Dovrei cancellare la cache ogni volta che ho modificato uno di questi file o non riconoscerebbe la versione più recente, nonostante IIS sia configurato per impedire la memorizzazione nella cache del client di questo file.
* Le richieste a clientaccesspolicy.xml e crossdomain.xml non venivano sempre visualizzate in Fiddler. Spesso vedrei richieste CONNECT invece. Non capisco la ragione di questo, ma ho imparato a non fare affidamento su Fiddler per confermare queste richieste. Forse ho qualche impostazione errata da qualche parte (e no non è l'impostazione "Decrypt HTTPS traffic" che ho già disabilitato).

3

Ho lo stesso errore, quando provo a effettuare una chiamata al mio sito tramite http e il mio servizio è scaduto su https non è riuscito. Questo errore si è verificato perché la mia ISS non ha certificato, quindi, quando l'app ha provato a scaricare il clientaccesspolicy, non è riuscita.

Dai un'occhiata a qualsiasi strumento di debug del tuo browser e cerca il file clientacccesspolicy, quindi controlla che sia scaricato.

Problemi correlati