2012-03-07 41 views
11

Tengo problemas al enviar solicitudes JSONP desde HTTPS sitio al sitio HTTP.HTTPS a HTTP solicitud JSONP

Tengo un entorno de prueba (no local) sobre https (con certificado válido) donde puedo ejecutar todas estas solicitudes cruzadas/"de protocolo cruzado" con éxito (con advertencias, pero sin errores).

salida de Google Chrome Javascript consola:

The page at https://my.test.environment/ ran insecure content from http://non.secure.site/service?jsonCallback=jsonp1331132928704 

Sin embargo, en la producción, (en Google App Engine, appspot subdominio) Google Chrome es el bloqueo de todas las solicitudes en espera de la confirmación del usuario.

Google Chrome Javascript salida de la consola (atención especial a [bloqueado] texto):

[blocked] The page at https://production.appspot.com/ ran insecure content from http://non.secure.site/service?jsonCallback=jsonp1331132928704 

Yo sé lo que estoy haciendo no es segura, pero estos servicios son proporcionados por terceros y no hay comunicación SSL disponible hasta el momento. Estoy realmente confundido con esto porque no entiendo por qué funciona (con advertencias) en el entorno de prueba y no en appspot (Google App Engine).

Intenté investigar los encabezados sin éxito.

cabeceras entorno de prueba:

Connection:Keep-Alive 
Content-Encoding:gzip 
Content-Language:es 
Content-Length:2524 
Content-Type:text/html;charset=utf-8 
Date:Wed, 07 Mar 2012 15:48:30 GMT 
Keep-Alive:timeout=15, max=100 
Set-Cookie: cookie_info... 
Vary:Accept-Encoding 

cabeceras AppSpot:

access-control-allow-credentials:false 
access-control-allow-origin:* 
cache-control:no-cache, must-revalidate 
content-encoding:gzip 
content-length:47890 
content-type:text/html; charset=utf-8 
date:Wed, 07 Mar 2012 14:52:02 GMT 
expires:Fri, 01 Jan 1990 00:00:00 GMT 
pragma:no-cache 
server:Google Frontend 
set-cookie: coookie_info.... 
status:200 OK 
vary:Accept-Encoding 
version:HTTP/1.1 

que no tienen idea de por qué esto está trabajando en envinroment prueba y el mismo enfoque se bloquea en AppSpot por Google Chrome.

¿Alguna idea?

+4

Chrome trata las páginas HTTPS de Google a menudo de manera diferente a las páginas HTTPS estándar (por ejemplo, verificaciones de certificados especiales). ¿Puede ser que este sea también el caso del contenido inseguro? – Robert

+0

Mayte tienes razón. De hecho, el problema solo ocurre cuando implementamos la aplicación en GAE (appspot usa el certificado de Google). Voy a excavar en eso. ¡Gracias! –

+0

Tengo el mismo problema en mi propio servidor y certificado (válido) ... – Stefano

Respuesta

1

Un proxy apache hará una solicitud al punto final en su nombre. Incluso puede tener solicitudes que no sean jsonp a un servicio (json, xml, imágenes, publicación, envío, eliminación, etc.) porque el navegador cree que está haciendo la solicitud al mismo dominio.

Su archivo de host virtual non.secure.site contendría algo así como

ProxyRequests Off 
ProxyPreserveHost On 
<Proxy *> 
    Allow from all 
</Proxy> 
ProxyPass /appspot https://production.appspot.com/ 
ProxyPassReverse /appspot https://production.appspot.com/ 

Una vez que lo creó sólo llamar al servicio como ...

http://non.secure.site/appspot/service?jsonCallback=jsonp1331132928704 

Google proxypass para obtener más información

https://serverfault.com/questions/429404/help-me-understand-how-to-use-proxypass

0

Si no tiene otra opción que nosotros Si no se asegura una API de terceros, usted mismo puede pensar en MITM.

Cree un script del lado del servidor al que solo se tendrá acceso a través de SSL y que actuará como un proxy o un reenviador entre su etiqueta y la API. De esta forma, puede aumentar la seguridad al hacer sus propios controles y validaciones de los datos, y como lo servirá bajo SSL, no obtendrá ningún error de "Contenido mixto".

Por cierto, no lo he probado, siempre existe la posibilidad de que los sitios con el certificado de Google servido por GAE actúen de manera diferente.

Espero que pueda ayudar.

0

Tengo el mismo problema para hacer lo mismo entre http y https. Es un problema de dominio cruzado.

Lo más importante que necesita es la página del lado del servidor que está utilizando para hacer curl tiene que establecer algunos encabezados para permitir la conexión http a https. Esto se encuentra debajo ....

header("Access-Control-Allow-Origin: your https url"); 
header("Access-Control-Allow-Methods: POST, GET"); 
header("Access-Control-Max-Age: 1728000"); 

header("Access-Control-Allow-Headers: Content-Type, Connection, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control"); 
header("Connection: close");