Ce n'est pas un problème d'effet, il devrait être lié à la récupération. Cross-domain?

J'ai fait une demande interdomaine et l'ai changée en axios pour faire la demande. Tout est normal. Quels paramètres doivent être configurés pour que Fetch prenne en charge l'interdomaine?

Je ne l'ai pas essayé spécifiquement, mais en regardant la documentation de fetch, il est dit que le traitement inter-domaines est cohérent avec XMLHTTPRequest. Cela pourrait-il être lié au fait que le cookie n'a pas été transféré? https://www.npmjs.com/package/whatwg-fetch#sending -cookies

Dans mon projet, le serveur est écrit en langage GO. Tant que le serveur est configuré pour prendre en charge / autoriser le cross-domain, la récupération du client ne nécessite pas de configuration supplémentaire;

Je pense que @xaviertung peut envisager de vérifier le journal du serveur pour analyser / localiser le problème. S'il s'agit d'un problème d'authentification, résolvez le problème d'authentification :)

À 8h30 le 18 novembre 2016, chencheng (云 谦) [email protected] a écrit:

Je ne l'ai pas essayé spécifiquement, mais en regardant la documentation de fetch, il est dit que le traitement inter-domaines est cohérent avec XMLHTTPRequest. Cela pourrait-il être lié au fait que le cookie n'a pas été transféré? https://www.npmjs.com/package/whatwg-fetch#sending -cookies https://www.npmjs.com/package/whatwg-fetch#sending -cookies
-
Vous recevez ceci parce que vous êtes abonné à ce fil de discussion.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/dvajs/dva/issues/282#issuecomment -261413729, ou désactivez le fil https://github.com/notifications/unsubscribe-auth/ACv7UniRkGq0Uv8XFBUeNMe5jBe5jBeG. 4

Merci, le problème est résolu, c'est le problème du réglage du mode et des identifiants.

Comment le résoudre, parlons du plan, d'autres personnes pourraient le rencontrer plus tard.

1. L'erreur générée par fetch n'a pas localisé clairement le problème et a été remplacée par une solution Promise (axios) pour savoir qu'il s'agissait d'un problème inter-domaines
   2. J'ai trouvé un article sur Internet pour résoudre facilement le problème interdomaine, définir le mode: no-cors et prendre quelques détours.
   3. Enfin, j'ai une meilleure compréhension de fetch en lisant les documents officiels de fetch, et j'ai finalement résolu le problème en définissant le mode; cors.
   Résumé: La clé pour résoudre les problèmes interdomaines réside dans la compréhension des protocoles xhr et http. La plus grande différence entre la spécification du mode Cors et no-cors est que cors passe par les options avant d'envoyer la zone de requête.

@sorrycc enseignant, j'ai également rencontré des problèmes avec l'

@AsceticBoy semble être un problème avec la console. Est-il équipé d'un filtre?

@xaviertung L'interface inter-site n'a besoin que de définir le mode; cors?
J'ai ajouté des informations d'identification: «inclure» dans l'en-tête, et je signalerai une erreur indiquant que la demande n'est pas autorisée.
Le débogage est maintenant gênant, je dois changer le domaine de coût à chaque fois, puis compiler le front-end et le mettre dans le projet back-end pour le débogage.
Comment dois-je configurer le backend nginx + tomcat (spring) que j'utilise?Merci

@wuyongdec doit vérifier si le serveur est ouvert pour permettre la configuration

@wuyongdec dora prend en charge le débogage

@xaviertung Le serveur a été ouvert, mais le serveur a refusé lorsque les informations d'identification: 'include' ont été ajoutées.

@jingchenxu Existe-t-il de la documentation?

J'ai rencontré ce problème car le proxy n'a pas été configuré dans .roadhogrc. L'invite est également un problème inter-domaines.

Remplacez l'adresse http://jsonplaceholder.typicode.com/ de la cible par votre propre adresse de serveur
"proxy": { "/api": { "target": "http://jsonplaceholder.typicode.com/", "changeOrigin": true, "pathRewrite": { "^/api" : "" } } }

@wuyongdec J'ai également rencontré le même problème que vous, l'avez-vous résolu? Comment cela a-t-il été résolu?

Séparez les extrémités avant et arrière pour la configuration interdomaine! ! ! Authentification sans cookies, configuration de l'authentification JWT! !
Résoudre l'incapacité aux requêtes inter-domaines,
Tout d'abord, ne définissez pas de proxy dans config.js. Cette configuration ne peut être utilisée que pour le développement local et sera invalide après la construction.

Mon plan:
Configurer en .env (créer dans le répertoire racine sinon)
Lors de la demande de l'API, lisez l'adresse du serveur. (Modifier request.js)

serveur nghin / apache / php plus
add_header Access-Control-Allow-Origin * always; ### (Depuis Nginx 1.7.5)

add_header Access-Control-Allow-Methods GET, POST, OPTIONS, HEAD, PUT;
add_header Access-Control-Allow-Headers "Autorisation, Content-Type";

Fentch frontal:
informations d'identification: 'omit' // Cela signifie que les cookies ne doivent pas être envoyés et que les demandes interdomaines sont requises
entête:{
Autorisation: localStorage.getItem ('login-token'),
}

Parmi eux, «Autorisation» fait référence à différentes configurations de différents serveurs, en fonction de la méthode d'authentification côté serveur

Enregistrez ce que j'ai fait ici.
Si les noms de domaine sont incohérents, veuillez vous assurer que le backend prend en charge le cross-domain.
Qu'il s'agisse de 200 400 500, il doit contenir des informations Access-Control-Allow-Origin et d'autres informations.
Les deux paramètres suivants sont portés dans l'en-tête de récupération

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

Le serveur nginx écrit l'en-tête suivant

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: 你的域名

À ce stade, obtenir la suppression de publication et ainsi de suite peuvent tous fonctionner normalement,
Cependant, lorsqu'il rencontre un autre problème, nginx a perdu Access-Control-Allow-Origin et d'autres informations lors du retour de 401, entraînant l'échec de l'obtention du statut de réponse à 401 (https://github.com/github/fetch/issues/201 # issueecomment-141777867)
Solution, nginx ajoute toujours
Syntaxe: | add_header name value [toujours];
http, serveur, emplacement, si sur place

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;
  }  
}