Error de seguridad Silverlight WCF + SSL - crossdomain.xml nunca solicitado

Question

(Veo varias preguntas relacionadas con mi problema, pero ninguna de las soluciones me funciona, ya que encuentro este problema en producción, no durante el desarrollo local, y tengo ya intenté todas las correcciones propuestas.)

Tengo una aplicación Silverlight 4 que utiliza servicios WCF hospedados por IIS. En producción, se accede a estos servicios a través de HTTPS. A pesar de tener a valid crossdomain.xml archivo sigo teniendo el famoso "Error de seguridad" al acceder al servicio:

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

Usando violinista puedo ver que no hay petición se hace a crossdomain.xml o clientaccesspolicy.xml. Hay una solicitud CONEXIÓN para el servidor, pero eso es todo.

He leído que este error, aunque indica un problema con crossdomain.xml/clientaccesspolicy.xml, también se puede generar cuando el servidor emite un certificado no válido. Esto no parece ser el caso en mi escenario.

estoy seguro de lo siguiente está configurado correctamente: 1.
crossdomain.xml es válida y alojado en la raíz del sitio
2. Los servicios funcionan (Tenemos otros clientes en diversas tecnologías que los utilizan , incluyendo Adobe Flex que se basa en crossdomain.xml.)
3. La aplicación Silverlight funciona (Funciona muy bien con los servicios y servicios locales en un servidor de desarrollo compartido ***)
4. La aplicación Silverlight ni siquiera intente solicitar crossdomain.xml o clientaccesspolicy.xml (según lo confirmado por Fiddler)
5. La aplicación Silverlight utiliza la configuración adecuada para acceder a WCF sobre https. A continuación se muestra la configuración:

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

¿Qué otra cosa puede causar este tipo de problema? ¿Podría ser porque los servidores web están balanceados de carga? ¿O hay algún problema con el certificado que no haya notado? Si al menos puede señalarme en la dirección correcta, sería muy apreciado.

(*** Algo que vale la pena señalar: me encontré con un problema similar en nuestro entorno de desarrollo. La aplicación Silverlight no pudo acceder a los servicios de WCF en un servidor de desarrollo compartido, a pesar de tener crossdomain.xml y no usar HTTPS . Trabajé alrededor al agregar el servidor de desarrollo como un sitio de confianza en IE. Sin embargo, esta misma solución no funciona para la producción, y aun así no sería una solución aceptable. Pero el hecho de que tenía que hacer esto en el entorno de desarrollo me preocupa que me he perdido algo en el camino ...)

Answer 1

El problema era que me faltaba clientaccesspolicy.xml. Tener crossdomain.xml no fue suficiente en este caso. I think esto se debe a que la invocación de WCF no fue solo un navegador cruzado sino también un protocolo cruzado (la aplicación Silverlight se sirvió a través de http pero los servicios se prestaron a través de https).

Además, mi clientaccesspolicy.xml tenía que permitir explícitamente el acceso de http de la siguiente manera:

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

Ahora funciona como un encanto.

Un par de cosas que me hicieron tropezar en el camino:
* Mi navegador almacenaba en caché clientaccesspolicy.xml y crossdomain.xml.Tendría que borrar mi caché cada vez que cambiara uno de esos archivos o no reconocería la versión más reciente, a pesar de que IIS está configurado para evitar el almacenamiento en memoria caché del cliente de este archivo.
* Las solicitudes de clientaccesspolicy.xml y crossdomain.xml no siempre aparecían en Fiddler. A menudo veía las solicitudes CONNECT. No entiendo el motivo, pero he aprendido a no confiar en Fiddler para confirmar que se están realizando estas solicitudes. Tal vez tengo algún ajuste deshonesto en algún lugar (y no, no es la configuración "Descifrar el tráfico HTTPS" que ya deshabilité).

Answer 2

Tengo el mismo error, cuando trato de hacer una llamada a mi sitio a través de http y mi servicio estaba por encima de https falló. Este error se produjo porque mi ISS no tenía certificado, por lo tanto, cuando la aplicación intentó descargar la política de acceso público, falló.

Eche un vistazo a cualquier herramienta de depuración en su navegador y busque el archivo clientacccesspolicy, luego verifique si se está descargando.