Problemas entre dominios
Entre dominios significa que la solicitud ha llegado al servidor, pero está restringida por el navegador cuando vuelve. Al igual que Python puede capturar datos, puedes obtener datos sin tener que pasar por un navegador para iniciar una solicitud. Pienso en usar el proxy inverso de Nginx para resolver problemas entre dominios.
Servidor proxy
Servidor proxy. Cuando el cliente envía una solicitud, no la envía directamente al host de destino, sino que primero la envía al servidor proxy. Una vez que el servicio proxy acepta la solicitud del cliente, la envía al host y recibe los datos devuelto por el host de destino y lo almacena en el proxy, en el disco duro del servidor lo envía al cliente.
Proxy de reenvío
El usuario conoce la dirección del servidor de destino, pero no puede acceder directamente a él debido a restricciones de red y otras razones. En este momento, primero debe conectarse al servidor proxy y luego el servidor proxy puede acceder al servidor de destino. Por ejemplo, no podemos acceder a Google, pero yo tengo un vps en el extranjero, puede acceder a Google, yo accedo a él, después de pedirle que acceda a Google, me envía los datos.
Proxy inverso
El llamado proxy inverso es justo lo opuesto al proxy de reenvío El servidor proxy sirve al servidor de destino, aunque la ruta de retorno de la solicitud general es la misma de Cliente a Proxy a Servidor.
Por ejemplo, cuando visitamos el sitio web de Baidu, el nombre de dominio externo del servidor proxy de Baidu es https://www.baidu.com. No conocemos el nodo del servidor interno específico. En realidad, después de que visitamos el servidor proxy de Baidu, el servidor proxy nos reenvía la solicitud a uno de sus N nodos de servidor para buscarnos y devolver el resultado.
Otro ejemplo: también necesitamos dinero, pero no sabemos quién tiene el dinero, por lo que encontramos una plataforma de préstamos en línea. Después de enviar la información, la plataforma de préstamos en línea le enviará el dinero directamente. Pero usted no sabe ni tiene que prestar atención a de dónde proviene el dinero de las plataformas de préstamos en línea. En la plataforma de préstamos en línea, de qué propietario adinerado pueden recaudar dinero. Para usted, la plataforma de préstamos en línea y su financiador son lo mismo.
También en el ejemplo anterior, podemos ver que el servidor proxy y el host de destino detrás son un sistema (compañía Baidu, plataforma de préstamos en línea). Proporcionan servicios al mundo exterior, por lo que se denominan agentes inversos y son las personas que están detrás.
Configuración de proxy inverso de Nginx
Cuando ocurre un error de dominio cruzado 403, el encabezado No'Access-Control-Allow-Origin 'está presente en el recurso solicitado, debe configurar los parámetros del encabezado de respuesta para el servidor Nginx
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
Configure los siguientes parámetros en Nginx:
location / {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
if ($request_method = 'OPTIONS') {
return 204;
}
}
Explicación
1. Acceso-Control-Permitir-Origen
El servidor no puede cruzar dominios de forma predeterminada. Access-Control-Allow-Origin *Después de configurar el servidor Nginx , significa que el servidor puede aceptar todas las fuentes de solicitud (Origen), es decir, aceptar todas las solicitudes entre dominios.
2. Access-Control-Allow-Headers es para evitar los siguientes errores:
El campo de encabezado de solicitud Content-Type no está permitido por Access-Control-Allow-Headers en la respuesta de verificación previa.
Este error indica que el valor del tipo de contenido solicitado actualmente no es compatible. De hecho, iniciamos la solicitud de tipo "application / json". Esto implica un concepto: solicitud de verificación previa (solicitud de verificación previa), consulte la introducción de "solicitud de verificación previa" a continuación.
3. Access-Control-Allow-Methods es para evitar los siguientes errores:
El tipo de contenido no está permitido por Access-Control-Allow-Headers en la respuesta previa al vuelo.
4. Agregue un retorno 204 a OPTIONS para manejar el error de que Nginx aún rechaza el acceso al enviar una solicitud POST. Al
enviar una "solicitud de verificación previa", se debe usar el método OPTIONS, por lo que el servidor debe permitir este método.
Solicitud de verificación previa
De hecho, la configuración anterior implica un estándar W3C: CROS, el nombre completo es Intercambio de recursos de origen cruzado (Intercambio de recursos de origen cruzado), se propone para resolver solicitudes de dominio cruzado.
El estándar Cross-Origin Resource Sharing (CORS) ha agregado un conjunto de campos de encabezado HTTP para permitir que el servidor declare qué sitios de origen tienen permiso para acceder a qué recursos. Además, la especificación requiere que para aquellos métodos de solicitud HTTP que pueden tener efectos secundarios en los datos del servidor (especialmente solicitudes HTTP distintas de GET o solicitudes POST con ciertos tipos MIME), el navegador debe usar primero el método OPTIONS para iniciar una Verifique la solicitud (solicitud de verificación previa) para saber si el servidor permite la solicitud entre dominios. Una vez que el servidor confirma el permiso, se inicia la solicitud HTTP real. En la devolución de la solicitud de verificación previa, el servidor también puede notificar al cliente si necesita llevar credenciales de identidad (incluidas las cookies y los datos relacionados con la autenticación HTTP).
De hecho, una solicitud cuyo campo Content-Type es application / json es la solicitud POST mencionada anteriormente con ciertos tipos MIME. CORS estipula que Content-Type que no pertenece a los siguientes tipos MIME es una solicitud de verificación previa:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Por lo tanto, la solicitud application / json agregará una solicitud de "verificación previa" antes de la comunicación formal. Esta vez, la solicitud de "verificación previa" traerá la información del encabezado Access-Control-Request-Headers: Content-Type:
OPTIONS /api/test HTTP/1.1
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type
Cuando el servidor responde, si la información de encabezado devuelta no contiene Access-Control-Allow-Headers: Content-Type, significa que no se acepta el Content-Type no predeterminado. El siguiente error ha ocurrido:
Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.