Tengo un sitio, foo.com, que realiza solicitudes de ajax a bar.foo.com. Esto funcionara.AJAX, Subdominios y SSL
Además, si foo es una conexión segura, https, ¿necesita bar.foo.com ser https también? ¿Pueden estos dos sitios usar diferentes certificados?
La mayoría de los navegadores, dependiendo de su configuración de seguridad/privacidad, bloquean cualquier llamada externa realizada y solo permiten llamadas AJAX realizadas en el mismo dominio. Incluso los subdominios están bloqueados, porque en entornos compartidos podrían representar una amenaza real.
En resumen: solo realice llamadas AJAX a través del mismo dominio (quizás llame a una página, que a su vez llame a otra página desde otro dominio - a través de curl/fopen/...), o se encontrará con problemas. Eso también responde a su pregunta de SSL: no importa qué SSL esté usando o si son iguales: las llamadas se bloquearán, a pesar del SSL.
Sí, puede obtener diferentes certs para ambos dominios. Todo depende de cómo decidas configurarlo.
Puede configurar un servidor web para foo.com y puede abrir el puerto 80 para no seguro y el puerto 443 para seguridad y usar ambos.
Puede configurar un servidor web diferente para bar.foo.com y hacer las mismas configuraciones de puerto.
Si necesita asegurarse de que está seguro en ambos, entonces necesita obtener certs para cada dominio diferente.
Es posible que pueda comprar un certificado * .foo.com que le permita copiar el certificado a otro sitio y usarlo.
Independientemente de si su solicitud vincula al http://bar.foo.com, no tendrá una conexión segura.
Tienes que tener los http "s" allí para decirle al servidor web que use el puerto 443 e intente validar el certificado.
Todos los certs realmente dicen que la fuente es de confianza. Incluso si no es de confianza y usted utiliza http "s" y hay un bloqueo en el navegador, sus datos se cifran de todos modos.
Con plain-http AJAX: Está hablando de hacer un dominio cruzado de XMLHttpRequest, que no está permitido por los navegadores. Hay un W3C proposal pending para implementar esto de una manera segura en el futuro (parcialmente implementado por IE8, IIRC), pero definitivamente no es posible en este momento.
Hay, sin embargo, soluciones para hacerlo de forma segura: Subspace (que utiliza marcos flotantes y document.domain), los fragment identifier technique (de nuevo, usa iframes) y window.name technique (de nuevo, iframes!).
En lo que respecta a SSL, puede comprar certificados por separado para el dominio y el subdominio, o un solo comodín (* .foo.com) certificado que los cubra a ambos (naturalmente, el certificado de comodín será más caro).
Si tiene una página HTTPS que solicita elementos de otros dominios, todo estará bien mientras todo sea HTTPS. Esto significa que si usa una de las soluciones provisionales de iframes, debe especificar una URL de esquema https:// en el atributo src del iframe.
Una solución final, menos eficiente, es tener una secuencia de comandos en https://foo.com que proxies solicitudes de inseguridad http://bar.foo.com.(Esto también resuelve el problema de dominios cruzados XHR, por lo que puede ignorar las otras soluciones). Por supuesto, eso significa que está enviando la solicitud de XHR al https://foo.com/someurl, luego está presionando http://bar.foo.com/someurl, recibiendo la respuesta y enviándola al navegador , por lo que en lo que respecta al rendimiento, es mucho mejor que simplemente mover la funcionalidad del servidor de bar.foo.com a foo.com, si tiene esa opción. Pero si no puede mover el script del servidor, entonces el proxy es el camino a seguir.
EDIT: me cambiaron los últimos 3 grafs después de hacer algunas pruebas adicionales y obtener una solución de marco flotante AJAX (la #fragmentidentifier uno) para trabajar a través de diferentes dominios HTTPS. Usted puede hacer AJAX de dominios cruzados SSL usando iframes siempre que todo sea https y el esquema https se use en el iframe src. En resumen:
puede co combine JavaScript TLS y Flash para realizar solicitudes seguras entre dominios. De esta manera, sus visitantes van al https://foo.com y pueden hacer que XmlHttpRequests sea https://bar.foo.com. Puedes hacer lo mismo con un http regular.
Deberá comprar un certificado SSL en el que los navegadores de sus visitantes confiarán para foo.com, pero puede generar sus propios certificados SSL para bar.foo.com, bar2.foo.com, etc. Una alternativa más costosa generar sus propios certificados SSL (que es gratis) es comprar un certificado SSL comodín para * .foo.com. Pero si solo hace solicitudes de dominio cruzado a esos sitios a través de foo.com, entonces no necesita gastar ese dinero extra.
Comprobar a cabo el proyecto de código abierto Forge en github:
http://github.com/digitalbazaar/forge/blob/master/README
Los enlaces de blogs al final proporciona una explicación más en profundidad.
Sí, lo más seguro es que pueda hacer envíos de dominio cruzado ajax. Hicimos la misma configuración usando un ssl.com wildcard cert pero puede usar 2 certs estándar en 2 sitios.
Básicamente, utilizaría JSONP (yahoo, google, fb, etc. use esto). El valor de retorno está envuelto en una función y se ve como
someFunction("{...}");