Es ist kein Effektproblem, es sollte mit dem Abrufen zusammenhängen. Domänenübergreifend?

Ich habe eine domänenübergreifende Anfrage gestellt und sie in axios geändert, um die Anfrage zu stellen. Alles ist normal. Welche Parameter müssen für den Abruf konfiguriert werden, um die domänenübergreifende Anfrage zu unterstützen?

Ich habe es nicht speziell ausprobiert, aber in der Abrufdokumentation heißt es, dass die domänenübergreifende Verarbeitung mit XMLHTTPRequest konsistent ist. Könnte es damit zusammenhängen, dass der Cookie nicht überbracht wurde? https://www.npmjs.com/package/whatwg-fetch#sending -cookies

In meinem Projekt ist der Server in der Sprache GO geschrieben. Solange der Server so konfiguriert ist, dass er domänenübergreifend unterstützt / zulässt, erfordert der Abruf des Clients keine zusätzliche Konfiguration.

Ich denke, @xaviertung kann in Betracht ziehen, das Serverprotokoll zu überprüfen, um das Problem zu analysieren / zu lokalisieren. Wenn es sich um ein Authentifizierungsproblem handelt, lösen Sie das Authentifizierungsproblem :)

Am 18. November 2016 um 8:30 Uhr schrieb chencheng (云 谦) [email protected] :

Ich habe es nicht speziell ausprobiert, aber in der Abrufdokumentation heißt es, dass die domänenübergreifende Verarbeitung mit XMLHTTPRequest konsistent ist. Könnte es damit zusammenhängen, dass der Cookie nicht überbracht wurde? https://www.npmjs.com/package/whatwg-fetch#sending -cookies https://www.npmjs.com/package/whatwg-fetch#sending -cookies
- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/dvajs/dva/issues/282#issuecomment -261413729 an oder schalten Sie den Thread https://github.com/notifications/unsubscribe-auth/ACv7UniRkGq0Uv8XFBUeNMeZyjp5BB5GB5GB5GB5GBp5. 4

Vielen Dank, das Problem ist gelöst, es ist das Problem der Einstellung von Modus und Anmeldeinformationen.

Wie man es löst, lassen Sie uns über den Plan sprechen. Andere Leute können ihm später begegnen.

1. Der durch den Abruf ausgelöste Fehler hat das Problem nicht eindeutig lokalisiert und in eine Promise-Lösung (Axios) geändert, um zu wissen, dass es sich um ein domänenübergreifendes Problem handelt
   2. Ich habe einen Beitrag im Internet gefunden, um das domänenübergreifende Problem einfach zu lösen, den Modus: no-cors einzustellen und einige Umwege zu machen.
   3. Schließlich habe ich ein tieferes Verständnis für das Abrufen, indem ich die offiziellen Dokumente des Abrufs lese, und schließlich habe ich das Problem durch Einstellen des Modus cors gelöst.
   Zusammenfassung: Der Schlüssel zur Lösung domänenübergreifender Probleme liegt im Verständnis der xhr- und http-Protokolle. Der größte Unterschied zwischen der Angabe des Modus als Cors und No-Cors besteht darin, dass Cors die Optionen s durchlaufen, bevor der Anforderungsbereich gesendet wird.

@sorrycc Lehrer, ich habe auch einige Probleme mit dem domänenübergreifenden Abrufen angezeigt . Der Hintergrund kann den Haltepunkt eingeben. Die Beurteilungsmethode ist GET (meine eigentliche Anforderung) und die Frontend verwendet response.json () Die Hintergrunddaten können ebenfalls abgerufen werden, aber die Konsole enthält keine Aufzeichnung von GET-Anforderungen, sondern nur Optionen. Wenn Sie Ajax verwenden, ist alles normal. Die Konsole verfügt sowohl über Options- als auch über GET-Anforderungen.

@AsceticBoy klingt so, als ob es ein Problem mit der Konsole sein sollte. Ist sie mit Filterung ausgestattet?

@xaviertung Cross-Site-Frontend muss nur den Modus einstellen; cors?
Ich habe Anmeldeinformationen hinzugefügt: 'include' in den Header, und ich werde einen Fehler melden, der besagt, dass die Anforderung nicht zulässig ist.
Das Debuggen ist jetzt problematisch. Ich muss jedes Mal die Kostendomäne ändern und dann das Front-End kompilieren und es zum Debuggen in das Back-End-Projekt einfügen.
Wie muss ich das von mir verwendete Nginx + Tomcat (Spring) Backend einrichten?Vielen Dank

@wuyongdec muss überprüfen, ob der Server geöffnet ist, um eine domänenübergreifende Konfiguration zu ermöglichen.

@wuyongdec dora unterstützt das domänenübergreifende Debuggen

@xaviertung Der Server wurde geöffnet, aber der Server lehnte ab, als Anmeldeinformationen hinzugefügt wurden: 'include'.

@jingchenxu Gibt es Unterlagen?

Ich bin auf dieses Problem gestoßen, weil der Proxy nicht in .roadhogrc konfiguriert wurde. Die Eingabeaufforderung ist auch ein domänenübergreifendes Problem.

Ändern Sie die http://jsonplaceholder.typicode.com/ des Ziels in Ihre eigene Serveradresse
"proxy": { "/api": { "target": "http://jsonplaceholder.typicode.com/", "changeOrigin": true, "pathRewrite": { "^/api" : "" } } }

@wuyongdec Ich bin auch auf das gleiche Problem gestoßen wie Sie. Haben Sie es gelöst? Wie wurde es gelöst?

Separates Front- und Backend für domänenübergreifende Konfiguration! ! ! Nicht-Cookies-Authentifizierung, JWT-Authentifizierungskonfiguration! !
Beheben Sie die Unfähigkeit, domänenübergreifende Anforderungen zu erfüllen.
Legen Sie zunächst keinen Proxy in config.js fest. Diese Konfiguration kann nur für die lokale Entwicklung verwendet werden und ist nach dem Erstellen ungültig.

Mein Plan:
In .env konfigurieren (falls nicht im Stammverzeichnis erstellen)
Lesen Sie die Serveradresse, wenn Sie die API anfordern. (Ändern Sie request.js)

nghin / apache / php server plus
add_header Access-Control-Allow-Origin * immer; ### (Seit Nginx 1.7.5)

add_header Zugriffssteuerungs-Zulassungsmethoden GET, POST, OPTIONS, HEAD, PUT;
add_header Access-Control-Allow-Header "Autorisierung, Inhaltstyp";

Front-End-Fentch:
Anmeldeinformationen: 'weglassen' // Dies bedeutet, dass keine Cookies gesendet werden sollen und domänenübergreifende Anforderungen erforderlich sind
Header:{
Autorisierung: localStorage.getItem ('Login-Token'),
}}

Unter diesen bezieht sich "Autorisierung" auf unterschiedliche Konfigurationen verschiedener Server, abhängig von der serverseitigen Authentifizierungsmethode

Nimm auf, was ich hier gemacht habe.
Wenn die Domainnamen inkonsistent sind, stellen Sie bitte sicher, dass das Backend domänenübergreifend unterstützt.
Unabhängig davon, ob es sich um 200 400 500 handelt, muss es Access-Control-Allow-Origin und andere Informationen enthalten.
Die folgenden zwei Parameter werden im Abrufheader enthalten

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

Der Nginx-Server schreibt den folgenden Header

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

Zu diesem Zeitpunkt können Sie nach dem Löschen usw. alle normal funktionieren.
Bei einem anderen Problem verlor nginx jedoch Access-Control-Allow-Origin und andere Informationen bei der Rückgabe von 401, was dazu führte, dass der Antwortstatus bei 401 (https://github.com/github/fetch/issues/201) nicht abgerufen wurde # issuecomment-141777867)
Lösung, fügt Nginx immer hinzu
Syntax: | add_header name value [immer];
http, Server, Standort, falls in Standort

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