Nginx behandelt verschiedene Probleme und Lösungen, auf die Cros in verschiedenen Domänen stößt, sowie die HTTPS-Konfiguration und die Behandlung unsicherer Browser-HTTPS-Probleme

---

Vorwort

提示：本人在生产部署服务时遇到一系列跨域问题和https配置问题,特此做以下记录：

Vorwort 1. Was ist domänenübergreifend?

Domänenübergreifend bedeutet, dass Seite a Ressourcen von Seite b erhalten möchte. Wenn die Protokolle, Domänennamen, Ports und Subdomänennamen der Seiten a und b unterschiedlich sind oder Seite a eine IP-Adresse und Seite b eine Domänennamenadresse ist Alle Zugriffsaktionen sind domänenübergreifend. Domäne, und Browser schränken aus Sicherheitsgründen im Allgemeinen den domänenübergreifenden Zugriff ein, dh domänenübergreifende Ressourcenanforderungen sind nicht zulässig.

Vorwort 2. Was sind die Bedingungen für die domänenübergreifende Generierung?

注意：跨域限制访问，其实是浏览器的限制。理解这一点很重要。所以，当用java（或者其他语言）调用RESTful api，从来不会报什么跨域错误

---

Zwei häufig verwendete Methoden für die domänenübergreifende Verarbeitung

1. Wie geht Springboot mit domänenübergreifenden Problemen um?

1.1 Separate Konfiguration im Controller

Fügen Sie jeder Controller-Klasse @CrossOrigin-domänenübergreifende Annotationen hinzu

1.2 Globale Konfiguration in der @configation-Klasse

@Configuration
public class CorsConfig implements WebMvcConfigurer {
    
    
    @Override
    public void addCorsMappings(CorsRegistry registry) {
    
    
        registry.addMapping("/**")  // 匹配了所有的URL
                .allowedHeaders("*")  // 允许跨域请求包含任意的头信息
                .allowedMethods("*")  // 设置允许的方法
                .allowedOrigins("*")  // 设置允许跨域请求的域名
                .allowCredentials(true);  // 是否允许证书，默认false
    }
}

1.3 Fügen Sie dem Filter einen Antwortheader hinzu

protected void doFilter(HttpServletRequest req, HttpServletResponse res, FilterChain chain) throws IOException, ServletException {
    
    
    res.addHeader("Access-Control-Allow-Origin", req.getHeader("Origin"));
    res.addHeader("Access-Control-Allow-Methods", "*");
    res.addHeader("Access-Control-Allow-Headers", "Accept,Authorization,DNT,Content-Type,Referer,User-Agent");
    res.addHeader("Access-Control-Allow-Credentials","true"); // 允许携带验证信息
    chain.doFilter(req, res);
}

2. Wie geht Nginx mit domänenübergreifenden Problemen um?

2.1 Konfigurieren Sie die Antwortheader-Parameter für den Nginx-Server

Wenn ein domänenübergreifender 403-Fehler auftritt und der Header „No „Access-Control-Allow-Origin““ auf der angeforderten Ressource vorhanden ist, müssen Sie die Antwortheaderparameter für den Nginx-Server konfigurieren.

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

2.2. Detaillierte Interpretation jedes Parameters

1. Zugriffskontrolle-Zulassen-Ursprung

服务器默认是不被允许跨域的,给Nginx服务器配置`Access-Control-Allow-Origin *`后，表示服务器可以接受所有的请求源（Origin）,即接受所有跨域的请求。

2. Access-Control-Allow-Headers soll die folgenden Fehler verhindern:

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

Dieser Fehler weist darauf hin, dass der Wert des aktuellen Anforderungsinhaltstyps nicht unterstützt wird. Tatsächlich wurde es dadurch verursacht, dass wir eine Typanfrage vom Typ „application/json“ initiierten. Hier handelt es sich um ein Konzept: Preflight-Anfrage (Preflight-Anfrage). Weitere Informationen finden Sie in der Einführung von „Preflight-Anfrage“ weiter unten.

3. Access-Control-Allow-Methods soll den folgenden Fehler verhindern:
   Content-Type is notallowed by Access-Control-Allow-Headers in Preflight Response.

4. Das Hinzufügen einer 204-Rückgabe zu OPTIONS dient dazu, den Fehler zu beheben, dass Nginx beim Senden einer POST-Anfrage immer noch den Zugriff verweigert

发送"预检请求"时，需要用到方法 OPTIONS ,所以服务器需要允许该方法。

Der Nginx-Konfigurationsdomänenname umfasst mehrere Domänennamen

Methode 1: Integrierte Nginx-Variablen verwenden (häufig verwendet)

server {
    
    
        set $cors '';
        if ($http_origin ~* "^http://deomain01:port$") {
    
    
            set $cors $http_origin;
        }
        if ($http_origin ~* "^http://deomain02:port$") {
    
    
            set $cors $http_origin;
        }
        if ($http_origin ~* "^http://deomain002:port$") {
    
    
            set $cors $http_origin;
        }
        location /live{
    
    
                  ...
                add_header 'Access-Control-Allow-Origin' '$cors';
                add_header 'Access-Control-Allow-Credentials' 'true';
                # 为预检请求加的header
                add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE';
                #为预检请求加的header
                add_header 'Access-Control-Allow-Headers' '*';
        }

Erläuterung: Das Format von $http_origin sieht vor, dass Nginx den Wert XXX im Header der Anfrage annimmt.
Hier wird der Ursprung genommen, und die allgemeine domänenübergreifende Anfrage setzt die Quelle der Anfrage in den Ursprung (der Browser fügt den Ursprungsheader zum Header der domänenübergreifenden Anfrage hinzu). Die Variable $ cors ruft die gewünschte domänenübergreifende Domäne
ab Namen und weist ihn „add_header ‚Access-Control-Allow-Origin‘ ‚$cors‘“ zu.

Methode 2: Karte verwenden

  map $http_origin $cors_list{
    
    
		default  http://aaa.cn;
	    "~ http://bbb.cn"  http://bbb.cn;
	}
    server {
    
    
        listen       8089;
        server_name  localhost;
        location /live{
    
    
                  ...
                add_header 'Access-Control-Allow-Origin' '$cors_list';
                add_header 'Access-Control-Allow-Credentials' 'true';
                # 为预检请求加的header
                add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE';
                #为预检请求加的header
                add_header 'Access-Control-Allow-Headers' '*';
        }

Erläuterung:
Der Kartenbefehl wird vom Modul ngx_http_map_module bereitgestellt, das standardmäßig von nginx geladen wird.

语法: map $var1 $var2 {
    
    …}
默认值: -
配置段: http

map为一个变量设置的映射表。映射表由两列组成，匹配模式和对应的值。

在map块里的参数指定了源变量值和结果值的对应关系。

default: 没有匹配结果将使用的默认值。如果没有设置default，将会用一个空的字符串作为默认的结果。

匹配模式可以是一个简单的字符串或者正则表达式，使用正则表达式要用(‘~’)。

Methode 3: Regelmäßiger Abgleich von Domainnamen der dritten Ebene

   location / {
    
    

             if ($http_origin ~* (http?://.*\.aliuncle\.top$)) {
    
    
                    add_header Access-Control-Allow-Origin $http_origin;
            }
            index index.php;
            try_files $uri $uri/ /index.php?$args;
    }

Hinweis: Denken Sie bei der domänenübergreifenden Konfiguration in der Konfigurationsdatei nginx.conf daran, den Client wie den Browser-Cache zu löschen, da sonst die Konfiguration nicht wirksam wird.

2.3 verarbeitet Nginx verschiedene Fehlerberichte, die im domänenübergreifenden Prozess auftreten

1. Die domänenübergreifende Anfrage kann den Cookie-Fehler für Identitätsanmeldeinformationen nicht enthalten ()

Beschreibung des Problems: Das Identitätsnachweis-Cookie kann ohnehin nicht in der Anfrage übergeben werden

Lösung:
Front-End:
1. Setzen Sie das Attribut withCredentials des Anforderungsobjekts auf true, wenn das Front-End eine Anfrage stellt.

2. Das Backend unterstützt den Antwortheader Credentials als true

注意：除了 Access-Control-Allow-Credentials 之外，跨域发送 Cookie 还要求 Access-Control-Allow-Origin 不允许使用通配符。 事实上不仅不允许通配符，而且 只能指定单一域名：
, andernfalls wird ein Cros-Fehler gemeldet

2.4, Fehler bei der Preflight-Anfrage (Preflight-Anfrage).

Einführung:
Der Cross-Origin Resource Sharing (CORS)-Standard fügt einen neuen Satz von HTTP-Header-Feldern hinzu, die es dem Server ermöglichen, zu deklarieren, welche Ursprungsseiten die Berechtigung zum Zugriff auf welche Ressourcen haben. Darüber hinaus erfordert die Spezifikation, dass der Browser für HTTP-Anfragemethoden, die Nebenwirkungen auf Serverdaten haben können (insbesondere andere HTTP-Anfragen als GET oder POST-Anfragen mit bestimmten MIME-Typen ), zunächst die OPTIONS-Methode verwenden muss, um eine Preflight-Anfrage zu initiieren (Preflight-Anfrage), um zu erfahren, ob der Server die domänenübergreifende Anfrage zulässt. Nachdem der Server die Berechtigung bestätigt hat, wird die eigentliche HTTP-Anfrage initiiert. Bei der Rückgabe der Preflight-Anfrage kann der Server dem Client auch mitteilen, ob er Identitätsanmeldeinformationen (einschließlich Cookies und HTTP-Authentifizierungsdaten) mitführen soll.
Tatsächlich ist die Anfrage, deren Content-Type-Feld application/json ist, die oben erwähnte POST-Anfrage mit bestimmten MIME-Typen. CORS legt fest, dass Content-Types, die nicht zu den folgenden MIME-Typen gehören, alle Vorabprüfungsanfragen sind:

application/x-www-form-urlencoded
multipart/form-data
text/plain

2.4.1. Erwarteter Anfrageprozess (zuerst Optionsanfrage/-antwort senden, dann Post-Anfrage senden)

2.4.2, Fehler bei der Vorabprüfung der Anfrage

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

Erläuterung:
Die Anwendungs-/JSON-Anfrage fügt vor der formellen Kommunikation eine „Vorabprüfung“-Anfrage hinzu. Diese „Vorabprüfung“-Anfrage bringt Header-Informationen. Wenn der Server antwortet und die zurückgegebenen Header-Informationen keine Zugriffskontrolle enthalten – Allow-Headers: Content-Type gibt an, dass ein nicht standardmäßiger Content-Type nicht akzeptiert wird. Das heißt, der obige Fehler tritt auf:

预检请求头信息
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

2.4.3. Wie kann der Fehlerbericht der Vorabprüfungsanforderung gelöst werden?

Die Preflight-Anfrage wurde ebenfalls bereits erwähnt. Wir müssen nur unsere Beurteilung vor dem Nginx-Proxy hinzufügen, damit Nginx einen Verarbeitungserfolgsstatuscode zurückgibt, wenn eine Optionsanforderung auftritt

//预检请求需要用到
    if ($request_method = 'OPTIONS') {
    
    
        return 204;
    }

Detaillierte Erläuterung des Nginx-Statuscodes

Detaillierte Erklärung von http

2.4.4 Access-Control-Allow-Origin kann nur einmal festgelegt werden, nach der Konfiguration im Backend kann es in nginx nicht erneut konfiguriert werden

Der folgende Fehler wird gemeldet:

Erläuterung: Der vom Server zurückgegebene Access-Control-Allow-Origin-Wert sollte keine Liste sein, da der Browser nur einen Wert akzeptiert und dieser nicht leer sein darf.

2.5. Der Anforderungsheader enthält zusätzliche Informationen wie die Autorisierung

Hinweis: (Die Autorisierung des Anforderungsheaderfelds ist durch Access-Control-Allow-Headers im Preflight nicht zulässig.)

2.5.1, Erläuterung

Der Antwortheader „Access-Control-Allow-Headers“ wird in der Preflight-Anfrage (Preflight-Anfrage) verwendet und listet die Header-Informationen auf, die im Feld „Access-Control-Request-Headers“ der formellen Anfrage angezeigt werden. Einfache Header, wie einfache Header, Accept, Accept-Language, Content-Language, Content-Type (beschränkt auf die drei MIME-Werte application/x-www-form-urlencoded, multipart/form-data oder text/plain nach dem Parsing-Typ (ohne Parameter)) werden sie immer unterstützt und müssen nicht speziell in diesem Header aufgeführt werden.

Zusätzliche Anforderungsheaderinformationen wie Autorisierung und X-Token müssen zugelassen werden. Dieser Fehler wird durch die Anforderungsvorverarbeitung gemeldet, um zu wissen, dass die Anforderungsheaderautorisierung nicht zulässig ist, sodass eine domänenübergreifende Meldung gemeldet wird

2.5.2. Lösen

Es ist notwendig, die zulässige Header-Autorisierung hinzuzufügen. Wenn festgestellt wird, dass es sich bei der Anforderungsmethode um Optionen handelt, geben Sie ok (200) an den Client zurück, damit die formelle Post-Anfrage fortgesetzt werden kann.

    add_header 'Access-Control-Allow-Origin' '*' always;
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PATCH, DELETE, PUT, 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, X-Custom-Header, Access-Control-Expose-Headers, Token, Authorization';
	add_header 'Access-Control-Allow-Headers'  '*';
    add_header 'Access-Control-Max-Age' 1728000;

2.6. Eingehende Analyse und Behebung von domänenübergreifenden Fehlern in der neuen Version von Google: Der Anforderungsclient ist kein sicherer Kontext und die Ressource befindet sich in einer privateren Adresse

2.6.1 Gründe für die Fehlermeldung

Fehler: Ein unsicherer Anforderer hat eine privatere lokale Ressource angefordert

Grund: Ab Version 94 von Google hat Google das private Netzwerk für unsichere Websites aktualisiert, um solche Anfragen zum Zugriff auf mehr private Ressourcen zu blockieren. Gleichzeitig wird vor der Anforderung privater Netzwerkressourcen zunächst eine OPTIONS-Preflight-Anfrage gesendet.

2.6.2 Lösungen

1. Ersetzen Sie Nicht-Google-Kernel-Browser (mit Firefox, Edge usw.) oder senken Sie die Version

2. Ändern Sie die Einstellungen von Google Chrome. Lösung
: Deaktivieren Sie die Einstellungen. Für Google Chrome-Versionen zwischen 94 und 101 können Sie die Browsereinstellungen ändern, sodass von http-Websites gesendete Anfragen nach privaten Ressourcen erfolgreich gesendet werden können.

Gehen Sie wie folgt vor:

Schritt 1: Geben Sie im Browser Folgendes ein: chrome://flags/#block-insecure-private-network-requests

Schritt 2: Ändern Sie die Standardeinstellung des Elements „Anfragen unsicherer privater Netzwerke blockieren“ auf „Deaktiviert“ und starten Sie den Browser neu (verschiedene Versionen haben unterschiedliche Konfigurationen, Einzelheiten finden Sie unter dem folgenden Referenzlink). Siehe Link 3. Ändern Sie die Zugriffsmethode von Intranet-Bilder und andere Ressourcen

.
Die Verwendung des https-Zugriffs kann das Problem grundsätzlich lösen

So konfigurieren Sie https (konfigurieren Sie SSL in Nginx)

1. Konfiguration

Fassen Sie die folgenden Schritte zusammen: SSL beantragen -> SSL-Dateispeicherung auf dem Server -> Nginx SSL konfigurieren

  server {
    
    
                listen       8002 ssl;          
                server_name temp.3zyun.com ;   #公网ip      115.148.208.122                                       
                client_max_body_size 1024M;
                ssl_certificate /usr/local/nginx/yjssl/7604469_temp.3zyun.com_nginx/7604469_temp.3zyun.com.pem;
        ssl_certificate_key /usr/local/nginx/yjssl/7604469_temp.3zyun.com_nginx/7604469_temp.3zyun.com.key;
        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;
        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on ;
                location / {
    
    
                         
                        proxy_pass http://bpm-server/;
                        proxy_set_header Host $host:$server_port;
                }
        }

注意 ：端口后面要加上ssl才可生效
Die SSL-Konfiguration wurde von diesem Artikel inspiriert

2. Eine Reihe von Problemen ist aufgetreten

2.1. Das h5-Projekt wird gepackt und für die Produktion bereitgestellt

Gemischter Inhalt: Die Seite unter „xxx“ wurde über HTTPS geladen, hat aber eine unsichere Ressource „xxx“ angefordert. Diese Anfrage wurde blockiert; der Inhalt muss über HTTPS bereitgestellt werden. Erklärung zur Problemlösung: Wenn unser Browser ähnlich aussieht wie „wurde geladen über“

. Der Fehler „HTTPS, aber eine unsichere Ressource/einen unsicheren Frame angefordert“ liegt im Allgemeinen daran, dass unsere Website HTTPS ist und der Link der anderen Partei ein HTTP-Protokoll ist. Wenn also Ajax- oder Javascript-Anfragen erfolgen, wird der obige Fehler gemeldet, wenn eine HTTP-Schnittstelle angefordert oder http-Ressourcen importiert werden in https wird direkt blockiert (blockiert), der Browser erkennt dieses Verhalten standardmäßig als unsicher an und blockiert es.

Lösung:

（在index.html的head中加入以下代码）
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

Funktion: Das Prinzip des Hinzufügens dieses Tags besteht darin, mithilfe des META-Tags http-Anfragen zwangsweise in https-Anfragen (SSL-Protokoll) umzuwandeln.

Zusammenfassen

Wachsen Sie immer, nachdem Sie ständig auf die Grube getreten sind! ! !