Dva: buscar problemas entre dominios

Creado en 17 nov. 2016  ·  18Comentarios  ·  Fuente: dvajs/dva

Llame al método de la capa de servicio en los efectos de la capa del modelo, el código es el siguiente:

// 引入service
import { login } from '../services/authentication';
// effects
*login({ payload: { currentUser } }, { select, call, put }) {
      const data = yield call(login, {
        "mobile": currentUser.userName,
        "password": currentUser.password
      });
      console.log('my response data is:', data);

La solicitud del servidor de vista del navegador es normal, pero los datos de impresión muestran el error generado por checkstatus, la respuesta devuelta antes de checkstatus es:

body:(...)
bodyUsed:false
headers:Headers
    __proto__: Headers
ok:false
status:0
statusText:""
type:"opaque"
url:""

Disculpe, ¿cuál podría ser el problema? La solicitud de vista del navegador devuelve un estado de 200, pero el código de estado http que se obtiene aquí es 0. ¿Es mi efecto o la búsqueda?

277 Por cierto, el problema de agregar encabezados sigue existiendo. También es la versión de dva6.0. ¿Podría ser el problema de la búsqueda isomórfica?

faq question

Comentario más útil

  1. El error arrojado por fetch no ubicó claramente el problema y cambió a una solución Promise (axios) para saber que se trataba de un problema de dominio cruzado
    2. Encontré una publicación en Internet para resolver fácilmente el problema entre dominios, configuré el modo: no-cors y tomé algunos desvíos.
    3. Finalmente, tengo una comprensión más profunda de fetch leyendo los documentos oficiales de fetch, y finalmente resolví el problema estableciendo mode; cors.
    Resumen: La clave para resolver problemas entre dominios radica en la comprensión de los protocolos xhr y http. La mayor diferencia entre especificar el modo como Cors y no-cors es que cors pasa por las opciones antes de enviar la solicitud.

Todos 18 comentarios

No es un problema de efectos, debería estar relacionado con la recuperación. ¿Dominio cruzado?

Hice una solicitud entre dominios y la cambié a axios para realizar la solicitud. Todo es normal. ¿Qué parámetros deben configurarse para que la recuperación sea compatible con dominios cruzados?

No lo he probado específicamente, pero al mirar la documentación de recuperación, se dice que el procesamiento entre dominios es consistente con XMLHTTPRequest. ¿Podría estar relacionado con el hecho de que no se trajo la cookie? https://www.npmjs.com/package/whatwg-fetch#sending -cookies

En mi proyecto, el servidor está escrito en lenguaje GO. Siempre que el servidor esté configurado para admitir / permitir dominios cruzados, la recuperación del cliente no requiere configuración adicional;

Creo que @xaviertung puede considerar revisar el registro del servidor para analizar / localizar el problema. Si es un problema de autenticación, resuelva el problema de autenticación :)

A las 8:30 am del 18 de noviembre de 2016, chencheng (云 谦) [email protected] escribió:

No lo he probado específicamente, pero al mirar la documentación de recuperación, se dice que el procesamiento entre dominios es consistente con XMLHTTPRequest. ¿Podría estar relacionado con el hecho de que no se trajo la cookie? https://www.npmjs.com/package/whatwg-fetch#sending -cookies https://www.npmjs.com/package/whatwg-fetch#sending -cookies
-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/dvajs/dva/issues/282#issuecomment -261413729, o silencie el hilo https://github.com/notifications/unsubscribe-auth/ACv7UniRkGq0Uv8XFBUeNMe5jBeGyWpKgaks5q_M. 4

Gracias, el problema está resuelto, es el problema de la configuración de modo y credenciales.

¿Cómo resolverlo, hablemos del plan? Otras personas pueden encontrarlo más tarde.

  1. El error arrojado por fetch no ubicó claramente el problema y cambió a una solución Promise (axios) para saber que se trataba de un problema de dominio cruzado
    2. Encontré una publicación en Internet para resolver fácilmente el problema entre dominios, configuré el modo: no-cors y tomé algunos desvíos.
    3. Finalmente, tengo una comprensión más profunda de fetch leyendo los documentos oficiales de fetch, y finalmente resolví el problema estableciendo mode; cors.
    Resumen: La clave para resolver problemas entre dominios radica en la comprensión de los protocolos xhr y http. La mayor diferencia entre especificar el modo como Cors y no-cors es que cors pasa por las opciones antes de enviar la solicitud.

@sorrycc profesor, también encontré algunos problemas con la búsqueda entre dominios. Después de usar la solicitud de búsqueda, apareció una solicitud de 200 opciones en la consola. El fondo puede ingresar al punto de interrupción. El método de evaluación es GET (mi solicitud real) y el front end usa response.json () Los datos de fondo también se pueden obtener, pero la consola no tiene un registro de solicitudes GET, solo Opciones. Si usa ajax, todo es normal. La consola tiene solicitudes Option y GET.

@AsceticBoy parece que debería ser un problema con la consola. ¿Está equipada con filtrado?

@xaviertung El end entre sitios solo necesita establecer el modo; ¿cors?
Agregué las credenciales: 'incluir' en el encabezado, y reportaré un error diciendo que la solicitud no está permitida.
La depuración es problemática ahora Tengo que cambiar el dominio de costos cada vez y luego compilar el front-end y ponerlo en el proyecto back-end para depurarlo.
¿Cómo necesito configurar el backend nginx + tomcat (spring) que uso?Gracias

@wuyongdec necesita verificar si el servidor está abierto para permitir la configuración entre dominios.

@wuyongdec dora admite la depuración entre dominios

@xaviertung El servidor se abrió, pero el servidor se negó cuando se agregaron las credenciales: 'incluir'.

@jingchenxu ¿Hay documentación?

Encontré este problema porque el proxy no estaba configurado en .roadhogrc. El mensaje también es un problema entre dominios.

Cambie el http://jsonplaceholder.typicode.com/ del objetivo a la dirección de su propio servidor
"proxy": { "/api": { "target": "http://jsonplaceholder.typicode.com/", "changeOrigin": true, "pathRewrite": { "^/api" : "" } } }

@wuyongdec También encontré el mismo problema que tú, ¿lo has resuelto? ¿Cómo se resolvió?

Separe el front-end y back-end para la configuración entre dominios. ! ! ¡Autenticación sin cookies, configuración de autenticación JWT! !
Resuelve la imposibilidad de realizar solicitudes entre dominios,
Primero, no establezca el proxy en config.js. Esta configuración solo se puede usar para el desarrollo local y no será válida después de la compilación.

Mi plan:
Configurar en .env (crear en el directorio raíz si no)
Al solicitar la API, lea la dirección del servidor. (Modificar request.js)

servidor nghin / apache / php plus
add_header Access-Control-Allow-Origin * siempre; ### (desde Nginx 1.7.5)

add_header Access-Control-Allow-Methods GET, POST, OPTIONS, HEAD, PUT;
add_header Access-Control-Allow-Headers "Autorización, tipo de contenido";

Fentch de front-end:
credenciales: 'omitir' // Esto significa que no se deben enviar cookies y se requieren solicitudes entre dominios
encabezamiento:{
Autorización: localStorage.getItem ('token de inicio de sesión'),
}

Entre ellos, "Autorización" se refiere a diferentes configuraciones de diferentes servidores, según el método de autenticación del lado del servidor.

Anota lo que hice aquí.
Si los nombres de dominio son inconsistentes, asegúrese de que el backend admita dominios cruzados.
No importa que sea 200 400 500, debe contener Access-Control-Allow-Origin y otra información.
Los siguientes dos parámetros se incluyen en el encabezado de búsqueda.

{
  mode: 'cors',
  credentials: 'include',
}

El servidor nginx escribe el siguiente encabezado

add_header Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Keep-Alive,User-Agent,Cache-Control,Content-Type,Authorization,sbid
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: 你的域名

En este momento, obtener la eliminación de publicaciones, etc., puede funcionar normalmente,
Sin embargo, cuando se encontró con otro problema, nginx perdió Access-Control-Allow-Origin y otra información al devolver el 401, lo que provocó que no se obtuviera el estado de respuesta en el 401 (https://github.com/github/fetch/issues/201 # issuecomment-141777867)
Solución, nginx agrega siempre
Sintaxis: | add_header name value [siempre];
http, servidor, ubicación, si está en la ubicación

server {
  listen       80;
  server_name  www.google.com;

  #charset koi8-r;
  #access_log  /var/log/nginx/host.access.log  main;

  location / {
    if ($request_method = 'OPTIONS') { 
      add_header Access-Control-Allow-Origin 'http://www.baidu.com' always;
      add_header Access-Control-Allow-Credentials 'true' always; 
      add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS' always;
      add_header Access-Control-Allow-Headers 'Keep-Alive,User-Agent,Cache-Control,Content-Type,Authorization,sbid' always;    
      return 200; 
    }

    root   /home/wwwroot/php;
    index  index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
  }

  location ~ \.php$ {
    add_header Access-Control-Allow-Origin 'http://www.baidu.com' always;
    add_header Access-Control-Allow-Credentials 'true' always; 
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS' always;
    add_header Access-Control-Allow-Headers 'Keep-Alive,User-Agent,Cache-Control,Content-Type,Authorization,sbid' always;  
    root /home/wwwroot/php/;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME           $document_root$fastcgi_script_name;
    include fastcgi_params;
  }  
}

server {
  listen       80;
  server_name  www.baidu.com;

  #charset koi8-r;
  #access_log  /var/log/nginx/host.access.log  main;

  location / {
    root   /home/wwwroot/view;
    try_files $uri $uri/ /index.html;
  }  
}
¿Fue útil esta página
0 / 5 - 0 calificaciones