Same-Origin-Policy: Protokolle, Portnummern und Hosts stimmen alle zu, Interaktionen zuzulassen, was ein Sicherheitsmechanismus für Browser ist.
Eins, jsonp domänenübergreifend
JSONP ist eine inoffizielle domänenübergreifende Lösung Nachteile: Unterstützt nur get, nicht post.
Prinzip: Mit Hilfe des src im script-Tag wird es nicht durch die Same-Origin-Policy eingeschränkt.
Das vom Client und Server üblicherweise verwendete Datenformat ist das JSON-Format. Wir können das Datenformat auf das JSON-Format einstellen. Da wir Skript (src-Attribut) verwenden, um Daten zu erhalten, wird ein Skript ausgeführt, sodass der Server eine Funktion an das Real auslagert In der Outsourcing-Schicht werden sie als Daten im JSON-Format zur Übertragung verwendet. Nachdem der Client sie erhalten hat, kann er die Funktion aufrufen, um die Daten abzurufen.
Grammatik, jsonp besteht aus drei Teilen: jsonp ( url , Daten (Parameter), Optionen (Callback-Funktion, kann mit Promise verwendet werden)) [kann auch mit jq implementiert werden (weggelassen)]
//前端发送请求，给发送请求的代码绑定的事件函数：
// 绑定事件 鼠标失去焦点
input.onblur = function () {
// 获取用户的输入值
let username = this.value
// 向服务器端发送请求 检测用户是否存在
// 1. 创建script标签
const script = document.createElement('script')
// 2. 设置标签的src属性
script.src = 'http://127.0.0.1:8000/checkusername'
// 3. 将script插入到文档中 不插入到文档中浏览器是不会发送请求的
document.body.appendChild(script)
}
//后端具体操作nodejs的server.js中
// checkusername
app.all("/checkusername", (request, response) => {
// response.send("hello jsonp server"); //这样返回的话浏览器解析不了
// response.send("console.log('hello jsonp-server')"); //返回的应该是一段js代码 是一个函数的调用
// 标准的样式
const data = {
exist: 1,
message: "用户名已经存在",
};
// 将数据转换成字符串
let str = JSON.stringify(data);
// 返回结果
response.end(`handle(${str})`); //返回的响应体
handle({"name":"汪汪队救火队长"})
});
2. Cross-Origin-Ressourcenfreigabe (CORS)
CORS (Cross-Origin Resource Sharing), ursprungsübergreifende Ressourcenfreigabe. CORS ist eine offizielle domänenübergreifende Lösung, die sich dadurch auszeichnet, dass sie keine speziellen Operationen auf der Client-Seite erfordert, vollständig auf dem Server verarbeitet wird und Get- und Post-Anforderungen unterstützt.
Der Prozess ist ein bisschen wie der TCP-Drei-Wege-Handshake:
Der Browser muss zuerst die OPTIONS-Methode verwenden, um eine Preflight-Anfrage (Preflight-Anfrage) zu initiieren, um zu wissen, ob der Server die Cross-Origin-Anfrage zulässt. Nachdem der Server die Berechtigung bestätigt hat, wird die eigentliche HTTP-Anforderung initiiert. Bei der Rückgabe der Preflight-Anforderung kann der Server den Client auch darüber informieren, ob Identitätsnachweise (einschließlich Cookies und HTTP-Authentifizierungsdaten) übertragen werden sollen.
3. Domänenübergreifendes WebSocket-Protokoll
Das WebSocket-Protokoll ist ein neues Protokoll von HTML5. In der Lage zu sein, eine Vollduplex-Kommunikation zwischen dem Browser und dem Server zu realisieren und gleichzeitig domänenübergreifend zu ermöglichen, ist eine gute Implementierung der serverseitigen Push-Technologie. WebSocket selbst hat keine domänenübergreifenden Probleme, sodass wir webSocket verwenden können, um zwischen unterschiedlichen Quellen zu kommunizieren. 【lernen】
Unter dem HTTP-Protokoll initiiert der Server nicht aktiv eine Anfrage an den Client, sondern antwortet nur.
Wenn Sie in diesem Zustand möchten, dass die Webseite das Feedback aktiv aktualisiert, wie z. B. Seitenspiele, die die Daten immer aktualisieren, besteht eine gängige Lösung darin, regelmäßig eine Anforderung zur Aktualisierung an den Server zu senden.
Lösung 2, lange Abfrage. Nachdem der Client eine Anfrage initiiert hat, wird die Timeout-Periode relativ lang eingestellt (z. B. 1 Min.) Wenn der Server nach dem Senden einer Anfrage nicht sofort neue Inhalte pusht, kann er immer noch antworten.
Das Wesen von http ist immer noch ein Halbduplex-Protokoll, daher ist es immer noch nicht auf Szenarien wie Spiele anwendbar, die eine große Menge an aktiver Datenübertragung erfordern, und das Websocket-Protokoll kann dieses Problem lösen.
websocket leiht sich http nur beim Verbindungsaufbau und hat dann nichts mit http zu tun
Vier, domänenübergreifender Nginx-Proxy
Prinzip: Die Same-Origin-Policy ist die Sicherheitsrichtlinie des Browsers, nicht Teil des HTTP-Protokolls. Die Serverseite ruft die HTTP-Schnittstelle nur unter Verwendung des HTTP-Protokolls auf, und es gibt kein Kreuzungsproblem.
Realisierung: Konfigurieren Sie den Proxy-Server über nginx (der Domänenname ist der gleiche wie test1 und der Port ist anders) als Sprungbrett, der Reverse-Proxy greift auf die test2-Schnittstelle zu und kann die Testinformationen im Cookie ändern, um das Schreiben von zu erleichtern das aktuelle Domain-Cookie und realisieren Cross-Domain-Login. Tatsächlich ist es wie das Prinzip der domänenübergreifenden Entwicklung.
Aufbau:
5. Domänenübergreifend während der Entwicklung, devServer.proxy (vue-cli Proxy-Weiterleitung)
Der Browser verbietet Cross-Domain, aber der Server verbietet es nicht.Wenn Befehle wie npm run dev lokal ausgeführt werden, führt es tatsächlich einen Server mit Knoten aus , sodass ProxyTable die Anfrage tatsächlich an seinen eigenen Server sendet und dann vom Server weitergeleitet wird Für den Hintergrundserver wurde er als Proxy verwendet, da es keine domänenübergreifenden Probleme geben wird.
Wir können einen Server lokal einrichten und dann den Server verwenden, um die Adresse der Hintergrundserverschnittstelle anzufordern
vuecli Scaffolding, starten Sie einen Webpack-Entwicklungsserver, er kann Proxy-Weiterleitung durchführen
Darüber hinaus haben das Frontend und dieser Server denselben Ursprung, beide sind Port 8080, und die Konfiguration des Webpack-Entwicklungsservers muss geändert werden.
So:
1. Es gibt kein domänenübergreifendes Problem zwischen dem Proxydienst und dem Front-End-Dienst aufgrund der Vereinheitlichung des Protokolldomänennamens und -ports, und die Anfrage kann direkt gesendet werden
2. Da der Proxy-Dienst und der Back-End-Dienst die Beschränkungen der Same-Origin-Policy des Browsers nicht durchlaufen, kann die Anfrage direkt gesendet werden
Auf diese Weise können wir die Schnittstelle durch den Server in der Mitte weiterleiten und das domänenübergreifende Problem in der Entwicklungsumgebung lösen. Es scheint ziemlich kompliziert. Tatsächlich hat vue-cli diese Technologie für uns gebaut. Wir müssen es nur tun entsprechend den Anforderungen konfigurieren. .
Das ist es:
devServer: {
proxy: {
// http://c.m.163.com/nc/article/headline/T1348647853363/0-40.html
'/api': { // 请求相对路径以/api开头的, 才会走这里的配置
target: 'http://c.m.163.com', // 后台接口域名 我们要代理的真实的接口地址
changeOrigin: true, // 改变请求来源(欺骗后台你的请求是从http://c.m.163.com)
pathRewrite: {
'^/api': '' // 因为真实路径中并没有/api这段, 所以要去掉这段才能拼接正确地址转发请求
}
}
}
}
//也就是说，客户端给代理服务器发送请求，客户端然后再向后端请求