Não é um problema de efeito, deve estar relacionado à busca. Domínio cruzado?

Fiz uma solicitação de vários domínios e alterei para axios para fazer a solicitação. Tudo está normal. Quais parâmetros devem ser configurados para busca para oferecer suporte a vários domínios?

Não tentei especificamente, mas olhando a documentação de busca, diz-se que o processamento entre domínios é consistente com XMLHTTPRequest. Isso pode estar relacionado ao fato de que o cookie não foi trazido? https://www.npmjs.com/package/whatwg-fetch#sending -cookies

No meu projeto, o servidor é escrito em linguagem GO. Contanto que o servidor esteja configurado para suportar / permitir domínio cruzado, a busca do cliente não requer configuração adicional;

Acho que @xaviertung pode considerar verificar o log do servidor para analisar / localizar o problema. Se for um problema de autenticação, resolva o problema de autenticação :)

Às 8h30 do dia 18 de novembro de 2016, chencheng (云 谦) [email protected] escreveu:

Não tentei especificamente, mas olhando a documentação de busca, diz-se que o processamento entre domínios é consistente com XMLHTTPRequest. Isso pode estar relacionado ao fato de que o cookie não foi trazido? https://www.npmjs.com/package/whatwg-fetch#sending -cookies https://www.npmjs.com/package/whatwg-fetch#sending -cookies
-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/dvajs/dva/issues/282#issuecomment -261413729 ou desative o encadeamento https://github.com/notifications/unsubscribe-auth/ACv7UniRkGq0Uv8XFBUeNMe5jBeGy_PKGyWpq. 4

Obrigado, o problema está resolvido, é o problema do modo e configuração de credenciais.

Como resolver, vamos conversar sobre o plano? Outras pessoas podem se deparar com isso mais tarde.

1. O erro gerado pela busca não localizou claramente o problema e mudou para uma solução Promise (axios) para saber que era um problema de domínio cruzado
   2. Encontrei uma postagem na Internet para resolver facilmente o problema entre domínios, configurei o modo: no-cors e fiz alguns desvios.
   3. Finalmente, tenho uma compreensão mais profunda de fetch lendo os documentos oficiais de fetch e, finalmente, resolvi o problema configurando o modo; cors.
   Resumo: A chave para resolver problemas de domínio cruzado reside na compreensão dos protocolos xhr e http.A maior diferença entre especificar o modo como Cors e no-cors é que cors passa pela opção s antes de enviar a área de solicitação.

@sorrycc professor, também encontrei alguns problemas com a busca entre domínios. Depois de usar a solicitação de busca, uma solicitação de 200 Opções apareceu no console. O plano de fundo pode inserir o ponto de interrupção. O método de julgamento é GET (minha solicitação real), e o front end usa response.json () Os dados de segundo plano também podem ser obtidos, mas o console não tem um registro de solicitações GET, apenas Opções. Se você usar ajax, tudo está normal. O console tem solicitações de Opção e GET.

Parece que @AsceticBoy deve ser um problema com o console. Ele está equipado com filtragem?

@xaviertung Cross-site front end só precisa definir o modo; cors?
Eu adicionei credenciais: 'incluir' no cabeçalho e relatarei um erro dizendo que a solicitação não é permitida.
A depuração é problemática agora. Tenho que alterar o domínio de custo todas as vezes e, em seguida, compilar o front-end e colocá-lo no projeto de back-end para depuração.
Como preciso configurar o back-end nginx + tomcat (spring) que uso?Obrigada

@wuyongdec precisa verificar se o servidor está aberto para permitir a configuração entre domínios.

@wuyongdec dora suporta depuração entre domínios

@xaviertung O servidor foi aberto, mas o servidor recusou quando as credenciais: 'include' foram adicionadas.

@jingchenxu Existe alguma documentação?

Encontrei este problema porque o proxy não foi configurado em .roadhogrc. O prompt também é um problema entre domínios.

Altere o http://jsonplaceholder.typicode.com/ do destino para o endereço do seu próprio servidor
"proxy": { "/api": { "target": "http://jsonplaceholder.typicode.com/", "changeOrigin": true, "pathRewrite": { "^/api" : "" } } }

@wuyongdec Eu também encontrei o mesmo problema que você, você já resolveu? Como foi resolvido?

Frente e back ends separados para configuração de domínio cruzado! ! ! Autenticação sem cookies, configuração de autenticação JWT! !
Resolva a incapacidade de solicitações entre domínios,
Primeiro, não defina o proxy em config.js. Esta configuração só pode ser usada para desenvolvimento local e será inválida após a construção.

Meu plano:
Configure em .env (crie no diretório raiz se não)
Ao solicitar a api, leia o endereço do servidor. (Modificar request.js)

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

add_header Access-Control-Allow-Methods GET, POST, OPTIONS, HEAD, PUT;
add_header Access-Control-Allow-Headers "Autorização, Tipo de Conteúdo";

Fentch frontal:
credentials: 'omit' // Isso significa que os cookies não devem ser enviados e as solicitações entre domínios são necessárias
cabeçalho:{
Autorização: localStorage.getItem ('login-token'),
}

Entre eles, "Autorização" refere-se a diferentes configurações de diferentes servidores, dependendo do método de autenticação do lado do servidor

Registre o que fiz aqui.
Se os nomes de domínio forem inconsistentes, certifique-se de que o back-end seja compatível com vários domínios.
Não importa se é 200 400 500, ele deve conter Access-Control-Allow-Origin e outras informações.
Os dois parâmetros a seguir são carregados no cabeçalho de busca

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

O servidor nginx grava o seguinte cabeçalho

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

Neste momento, get post delete e assim por diante podem funcionar normalmente,
No entanto, ao encontrar outro problema, nginx perdeu Access-Control-Allow-Origin e outras informações ao retornar 401, resultando na falha ao obter o status de resposta em 401 (https://github.com/github/fetch/issues/201 # issuecomment-141777867)
Solução, nginx adiciona sempre
Sintaxe: | add_header name value [sempre];
http, servidor, localização, se em localização

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