Alojando contenido estático en diferentes dominios de los servicios web, ¿cómo evitar el dominio cruzado?

Question

Recientemente hemos estado trabajando en una aplicación web bastante moderna y estamos listos para desplegarla para alpha/beta y obtener experiencia en el mundo real con ella.

Tenemos servicios web basados ​​en ASP.Net (API web) y un front-end de JavaScript que es 100% MVC del lado del cliente utilizando la red troncal.

Hemos comprado nuestro nombre de dominio, y por el bien de esta pregunta nuestro despliegue se ve así:

webservices.mydomain.com (Servicios Web)

mydomain.com (JavaScript front-end)

Si el JavaScript intenta hablar con los servicios web en el subdominio explotamos con problemas de dominio cruzado, he jugado con CORS pero no estoy satisfecho con el soporte de navegador cruzado, así que estoy contando esto como una opción.

En nuestras PC de desarrollo hemos utilizado un proxy inverso de IIS para reenviar todas las solicitudes a mydomain.com/webservices a webservices.mydomain.com - Lo cual resuelve todos nuestros problemas ya que el navegador cree que todo está en el mismo dominio.

Así que mi pregunta es, en una implementación pública, ¿cómo se resuelve este problema más comúnmente? Es un proxy inverso la forma correcta de hacerlo? Si es así, ¿hay algún servicio alojado que ofrezca un proxy inverso para esta situación? ¿Hay mejores formas de implementar esto?

Quiero usar CloudFront CDN ya que todos nuestros servidores/servicios están alojados en Amazon, pero estoy luchando por encontrar información sobre si un CDN puede admitir este tipo de configuración.

Gracias

Answer 1

Lo que están tratando de hacer es llamadas entre subdominio, y no del todo entre dominios. Que son trucos para eso: http://www.tomhoppe.com/index.php/2008/03/cross-sub-domain-javascript-ajax-iframe-etc/

Como se le preguntó cómo se resuelve este problema más comúnmente. Mi respuesta es: este problema es comúnmente EVITADO. En el mundo real, configuraría sus dominios de forma tal que no tenga que realizar tales operaciones solo para ejecutar su aplicación o configurar un servidor proxy para reenviar las llamadas. JSONP es también una solución de hack-ish.

Answer 2

Simplemente puede usar JSONP para solicitudes AJAX, pero el dominio cruzado no es un problema.

Si las solicitudes AJAX devuelven algo de HTML, se puede escapar a una cadena JSON.

El segundo es un poco incómodo, sin embargo.

Answer 3

Usted tiene 2/3 capas

en el servicio web clase behin de código, agregue este atributo: <System.Web.Script.Services.ScriptService()> _

tal vez usted necesita agregar esto en el nodo System.web de su web. config:

<webServices> 
     <protocols> 
      <add name="AnyHttpSoap"/> 
      <add name="HttpPost"/> 
      <add name="HttpGet"/> 
     </protocols> 
     </webServices> 

En la interfaz del lado del cliente

-Añadir referencia web al servicio en el subdominio (ej. webservices.mydomain.com/svc.asmx) Visual Studio crea la "clase de proxy"

funcionalidad -add en el masterpage | de la página | código de control de det llamar -Simplemente esto funciona desde el lado del cliente

Puede utilizar la funcionalidad de AJAX con scriptmanager o use otro sistema como JQuery.

Si su sitio web principal está compilado en .NET 3.5 o una versión anterior, debe agregar una referencia al espacio de nombres System.Web.Extensions y declararlo en su archivo web.config.

Answer 4

Si tiene el ancho de banda (E/S de red y CPU) para manejar esto, un proxy inverso es una excelente solución. Un buen proxy inverso incluso almacenará en caché las llamadas estáticas para ayudar a mitigar el retraso de red introducido por el proxy.

La otra opción es configurar los archivos de política de dominio cruzado y/o encabezados adecuados. Hacer esto en algunos proveedores de la nube puede ser difícil o incluso imposible. Recientemente me encontré con problemas con los archivos de fuentes e IE no está contento con las llamadas de dominio cruzado. No pudimos obtener el proveedor de almacenamiento en la nube que estábamos utilizando para configurar los encabezados correctos, por lo que los alojamos localmente en lugar de tener que lidiar con un proxy inverso.

Answer 5

Para permitir este servicio Web que se llama desde el guión, usando ASP.NET AJAX, añadir la siguiente línea al primer servicio web de código subyacente:

[System.Web.Script.Services.ScriptService] 

Answer 6

easyXDM es un plug-in a través de dominios Javascript que puede vale la pena explorar Hace uso de estándares cuando el navegador los admite y abstrae los diversos hacks necesarios cuando el navegador no es compatible con los estándares. De easyXDM.net:

easyXDM es una librería Javascript que le permite como desarrollador a trabajar fácilmente alrededor de la limitación establecida en el lugar por la política del mismo origen , a su vez, por lo que es fácil de comunicar y exponer Javascript API a través de los límites del dominio.

En el núcleo easyXDM proporciona una pila de transporte capaz de pasar mensajes basados ​​ de cuerda entre dos ventanas, un consumidor (el principal documento) y un proveedor (un documento incluye el uso de un iframe). Es lo hace mediante el uso de una de varias técnicas disponibles, siempre seleccionando la más eficiente para el navegador actual. Para todas las implementaciones , la pila de transporte ofrece bidireccionalidad, confiabilidad , puesta en cola y verificación de remitente.

Uno de los objetivos de easyXDM es admitir todos los navegadores que están en el uso común de , y proporcionar las mismas características para todos. Una de las estrategias para lograr esto es seguir estándares definidos, más usando la detección de características para asegurar el uso de la más eficiente.

Para citar autor fácil de XDM:

... sitios como LinkedIn, Twitter y Disqus, así como las aplicaciones se ejecutan por Nokia y otros han construido sus aplicaciones en la parte superior del marco de mensajería proporcionado por easyXDM.

Así que easyXDM claramente no es un poxy hack, pero admito que es una gran dependencia para asumir su proyecto.

El estado actual de la web es que si desea insertar el sobre, debe usar detección de características y rellenos, o simplemente forzar a los usuarios a actualizar a un navegador HTML5. Si eso te hace retorcerse, no estás solo, pero los polyfills son una especie de mal temporal necesario para llegar desde donde está la web a donde nos gustaría.

Véase también this SO question.