Acceso de JavaScript del dominio principal al subdominio?
cross-domain cross-domain-policy (1)
He leído que la configuración document.domain = "example.com" me permite acceder al dominio principal desde un subdominio.
¿Funcionará lo mismo al revés?
Digamos que mi sitio principal se está ejecutando en http://example.com . Todas las funciones de la API a las que quiero acceder a través de AJAX (GET & POST) están alojadas en http: // api .example.com .
¿ api.example.com acceder a api.example.com desde example.com ?
EDIT : Mirando document.domain otra vez, no creo que esto solucione el problema. El resultado de las llamadas a api .example.com no es un HTML necesario, sino un resultado de un script PHP que se ejecuta en el servidor API. Puede ser JSON, texto sin formato, etc., por lo que no hay forma de configurar document.domain para eso (ya que no es un iframe).
Necesitas configurar document.domain en AMBAS páginas
También puede configurar los encabezados CORS en su servidor:
http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/
Una descripción rápida de CORS
Firefox 3.5 y Safari 4 implementan la especificación CORS, utilizando XMLHttpRequest como un "contenedor de API" que envía y recibe los encabezados adecuados en nombre del desarrollador web, lo que permite las solicitudes entre sitios. IE8 implementa parte de la especificación CORS, utilizando XDomainRequest como un "contenedor API" similar para CORS, permitiendo simples solicitudes GET y POST entre sitios. En particular, estos navegadores envían el encabezado ORIGEN, que proporciona el esquema (http: // o https: //) y el dominio de la página que realiza la solicitud entre sitios. Los desarrolladores de servidores deben asegurarse de enviar de vuelta los encabezados correctos, especialmente el encabezado de Access-Control-Allow-Origin para el ORIGEN en cuestión (o "*" para todos los dominios, si el recurso es público).
El estándar CORS funciona al agregar nuevos encabezados HTTP que permiten que los servidores sirvan recursos a los dominios de origen permitidos. Los navegadores admiten estos encabezados y aplican las restricciones que establecen. Además, para los métodos de solicitud HTTP que pueden causar efectos secundarios en los datos del usuario (en particular, para los métodos HTTP que no sean GET, o para el uso de POST con ciertos tipos MIME), la especificación exige que los navegadores "revisen" la solicitud, solicitando métodos compatibles desde el servidor con un encabezado de solicitud de OPCIONES HTTP, y luego, tras la "aprobación" del servidor, se envía la solicitud real con el método de solicitud HTTP real. Los servidores también pueden notificar a los clientes si se deben enviar las "credenciales" (incluidas las cookies y los datos de autenticación HTTP) con las solicitudes.