跨域

跨域的容许次要有服务器端管制。服务器端通过在响应的header中设置Access-Control-Origin及相干一系列参数，提供跨域拜访的容许策略 设置响应头中的参数来容许跨域域申请： Access-Control-Allow-CredentialsAccess-Control-Allow-Origin 标识容许跨域的申请有哪些在POM文件中引入依赖<!-- 解决跨域问题所需依赖 --><dependency> <groupId>com.thetransactioncompany</groupId> <artifactId>cors-filter</artifactId> <version>2.5</version></dependency>在web.xml中配置跨域filter<!-- 配置跨域过滤器 --><filter> <filter-name>corsFilter</filter-name> <filter-class>cors-filter</filter-class></filter><filter-mapping> <filter-name>corsFilter</filter-name> <url-pattern>/*</url-pattern></filter-mapping>

01、索引https://waterflow.link/articles/1665656761584 1、为什么跨域跨域资源共享 (CORS) 是一种基于 HTTP 标头的机制，它容许服务器批示除其本身之外的任何起源（域、计划或端口），浏览器应容许从中加载资源。 CORS 还依赖于一种机制，浏览器通过该机制向托管跨域资源的服务器收回“预检”申请，以查看服务器是否容许理论申请。 在该预检中，浏览器发送批示 HTTP 办法的标头和将在理论申请中应用的标头。 跨域申请的示例：从 https://a.com 提供的前端 JavaScript 代码应用 ajax 向 https://b.com/data.json 发出请求。 出于平安起因，浏览器限度从脚本发动的跨域 HTTP 申请。 例如，ajax 和 申请的 API 遵循同源策略。 这意味着应用这些 API 的 Web 应用程序只能从加载应用程序的同一起源申请资源，除非来自其余起源的响应蕴含正确的 CORS 标头。 2、跨域的规定CORS规范通过增加新的 HTTP 头来工作，服务器能够返回容许哪些起源从 Web 浏览器读取该信息。此外，对于可能对服务器数据造成副作用的 HTTP 办法（特地是 GET 以外的 HTTP办法 ，或具备某些 MIME 类型的 POST），标准要求浏览器“预检”申请（先发送OPTIONS申请），而后在服务器“容许”后发送理论申请。 CORS 失败会导致谬误，但出于平安起因，JavaScript 无奈取得无关谬误的详细信息。所有代码都晓得产生了谬误。确定具体出了什么问题的惟一办法是查看浏览器的控制台以获取详细信息。 3、跨域场景1、不会触发预检简略的申请不会触发预检，那什么是简略的申请呢？ 首先申请办法必须是GET、HEAD、POST其中之一除了客户端主动设置的header头（比方：Connection、User-Agent等），只能设置如下的这些header头 AcceptAccept-LanguageContent-LanguageContent-Type：只容许application/x-www-form-urlencoded、multipart/form-data、text/plain类型Range：只能是一些简略的header头，比方bytes=256-或者bytes=127-255上面是一个简略申请的流程： 首先客户端会向a.com会向服务端b.com发送申请，并带上源域名。作为响应，服务器返回一个带有 Access-Control-Allow-Origin: * 的 Access-Control-Allow-Origin 标头，这意味着该资源能够被任何起源拜访。（个别容许某个域或者某几个域，能够用正则）2、会触发预检和简略申请不同，处于平安思考，会先向“预检”申请，浏览器首先应用 OPTIONS 办法向另一个源上的资源发送 HTTP 申请，以确定理论申请是否能够平安发送。 上面是预检申请的流程： 首先客户端header头曾经不合乎简略申请的header，这时会触发预检。客户端发送OPTIONS申请，以获取容许跨域的header头，会返回204 No Content的状态码预检胜利之后，客户端会发送失常的POST申请3、nginx跨域配置留神：如果nginx设置跨域反复，客户端console也会提醒反复跨域 ...

前言Nginx: 在上一篇我提到的跨域配置是正式上线的时候应用nginx做为配置的参考。Webpack: 而咱们更多的时候是在开发阶段就须要通过跨域进行联合开发各个子利用局部性能DevServer配置解决跨域子利用动态资源跨域 在webpack.config.js或者vue.config.js找到devServer属性；配置如下： devServer: { headers: { 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Credentials': true, 'Access-Control-Allow-Methods': 'GET,POST,OPTIONS,PUT,DELETE,FETCH', 'Access-Control-Allow-Headers': 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization' }, }子利用接口代理跨域 在webpack.config.js或者vue.config.js找到proxy属性；配置如下： devServer: { proxy: { '/api': { target: 'http://xxx.xx.xx.x', changeOrigin: true, pathRewrite: { '^/api': '' }, onProxyRes: function (proxyRes, req, res) { if (req.method === 'OPTIONS') { proxyRes.headers['Access-Control-Allow-Origin'] = req.headers.origin || '*' proxyRes.headers['Access-Control-Allow-Credentials'] = true proxyRes.headers['Access-Control-Allow-Methods'] = 'GET,POST,OPTIONS,PUT,DELETE,FETCH' proxyRes.headers['Access-Control-Allow-Headers'] = 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization' proxyRes.statusCode = 204 } else { proxyRes.headers['Access-Control-Allow-Origin'] = req.headers.origin || '*' proxyRes.headers['Access-Control-Allow-Credentials'] = true } } } }}也能够通过一些其余配置实现：这样就能在开发阶段子利用能够间接在父利用内随便拜访了。不太懂得敌人们能够。留言问我。 ...

什么是跨域域： 是指浏览器不能执行其余网站的脚本跨域： 它是由浏览器的 同源策略 造成的,是浏览器对 JavaScript 施行的平安限度，所谓同源（即指在同一个域）就是两个页面具备雷同的协定 protocol，主机 host 和端口号 port 则就会造成 跨域 跨域场景场景的跨域场景有哪些，请参考下表以后url申请url是否跨域起因http://www.autofelix.cnhttp://www.autofelix.cn/api.php否协定/域名/端口都雷同http://www.autofelix.cnhttps://www.autofelix.cn/api.php是协定不同http://www.autofelix.cnhttp://www.rabbit.cn是主域名不同http://www.autofelix.cnhttp://api.autofelix.cn是子域名不同http://www.autofelix.cn:80http://www.autofelix.cn:8080是端口不同 解决跨域的四种形式nginx的反向代理应用 nginx 反向代理实现跨域，是最简略的跨域形式只须要批改 nginx 的配置即可解决跨域问题，反对所有浏览器，反对session，不须要批改任何代码，并且不会影响服务器性能// nginx配置server { listen 81; server_name www.domain1.com; location / { proxy_pass http://www.domain2.com:8080; #反向代理 proxy_cookie_domain www.domain2.com www.domain1.com; #批改cookie里域名 index index.html index.htm; # 当用webpack-dev-server等中间件代理接口拜访nignx时，此时无浏览器参加，故没有同源限度，上面的跨域配置可不启用 add_header Access-Control-Allow-Origin http://www.domain1.com; #以后端只跨域不带cookie时，可为* add_header Access-Control-Allow-Credentials true; }}jsonp申请jsonp 是服务器与客户端跨源通信的罕用办法。最大特点就是简略实用，兼容性好 兼容低版本IE，毛病是只反对 get 申请，不反对 post 申请原理时网页通过增加一个 <script> 元素，向服务器申请 json 数据，服务器收到申请后，将数据放在一个指定名字的回调函数的参数地位传回来//jquery实现<script>$.getJSON('http://autofelix.com/api.php&callback=?', function(res) { // 解决取得的数据 console.log(res)});</script>后端语言代理能够通过一种没有跨域限度的语言直达一下，通过后端语言去申请资源，而后再返回数据比方 http://www.autofelix.cn 须要调用 http://api.autofelix.cn/userinfo 去获取用户数据，因为子域名不同，会有跨域限度能够先申请 http://www.autofelix.cn 下的 php 文件，比方 http://www.autofelix.cn/api.php，而后再通过该 php 文件返回数据// api.php 文件中的代码public function getCurl($url, $timeout = 5){ $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_TIMEOUT, $timeout); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE); $result = curl_exec($ch); curl_close($ch); return $result;}$result = getCurl('http://api.autofelix.cn/userinfo');return $result;后端语言的设置次要通过后端语言被动设置跨域申请，这里以 php 作为案例// 容许所有域名拜访header('Access-Control-Allow-Origin: *');// 容许单个域名拜访header('Access-Control-Allow-Origin: https://autofelix.com');// 容许多个自定义域名拜访static public $originarr = [ 'https://autofelix.com', 'https://baidu.com', 'https://csdn.net',];// 获取以后跨域域名$origin = isset($_SERVER['HTTP_ORIGIN']) ? $_SERVER['HTTP_ORIGIN'] : '';if (in_array($origin, self::$originarr)) { // 容许 $originarr 数组内的 域名跨域拜访 header('Access-Control-Allow-Origin:' . $origin); // 响应类型 header('Access-Control-Allow-Methods:POST,GET'); // 带 cookie 的跨域拜访 header('Access-Control-Allow-Credentials: true'); // 响应头设置 header('Access-Control-Allow-Headers:x-requested-with,Content-Type,X-CSRF-Token');}

跨域，对后端工程师来说，堪称既相熟又生疏。 这两个月我以架构师的角色参加一款教育产品的孵化，有了一段难忘的跨域之旅。 写这篇文章，我想分享我在跨域这个知识点的经验和思考，心愿对大家有所启发。 1 遇见跨域产品有多端：机构端，局方端 ，家长端等 。每端都有独立的域名，有的是在PC上拜访，有的是通过微信公众号来拜访，有的是扫码后H5展示。 接入层调用的接口域名对立应用 api.training.com这个独立的域名，通过Nginx来配置申请转发。 通常，咱们提到的跨域指：CORS。 CORS是一个W3C规范，全称是"跨域资源共享"（Cross-origin resource sharing）, 它须要浏览器和服务器同时反对他，容许浏览器向跨源服务器发送XMLHttpRequest申请，从而克服 AJAX 只能同源应用的限度。 那么如何定义同源呢？咱们先看下一个典型的网站的地址： 同源是指：协定、域名、端口号完全相同。 下表给出了与 URL http://www.training.com/dir/page.html 的源进行比照的示例: 当用户通过浏览器拜访利用（http://admin.training.com）时，调用接口的域名非同源域名(http://api.training.com)，这是不言而喻的跨域场景。 2 CORS详解跨域资源共享规范新增了一组 HTTP 首部字段，容许服务器申明哪些源站通过浏览器有权限拜访哪些资源。 标准要求，对那些可能对服务器数据产生副作用的 HTTP 申请办法（特地是 GET 以外的 HTTP 申请，或者搭配某些 MIME 类型的 POST 申请），浏览器必须首先应用 OPTIONS 办法发动一个预检申请（preflight request），从而获知服务端是否容许该跨域申请。 服务器确认容许之后，才发动理论的 HTTP 申请。在预检申请的返回中，服务器端也能够告诉客户端，是否须要携带身份凭证（包含 Cookies 和 HTTP 认证相干数据）。 2.1 简略申请当申请同时满足如下条件时，CORS验证机制会应用简略申请， 否则CORS验证机制会应用预检申请。 应用GET、POST、HEAD其中一种办法；只应用了如下的平安首部字段，不得人为设置其余首部字段； AcceptAccept-LanguageContent-LanguageContent-Type 仅限三种之一：text/plain，multipart/form-data，application/x-www-form-urlencoded：HTML头部 header field字段：DPR、Download、Save-Data、Viewport-Width、WIdth申请中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象能够应用 XMLHttpRequest.upload 属性拜访；申请中没有应用 ReadableStream 对象。简略申请模式，浏览器间接发送跨域申请，并在申请头中携带Origin的头，表明这是一个跨域的申请。 服务器端接到申请后，会依据本人的跨域规定，通过Access-Control-Allow-Origin和Access-Control-Allow-Methods响应头，来返回验证后果。 ...

什么是跨域跨域问题是前端开发人员背后绕不过来的问题。所谓跨域，艰深点表白，就是以后站点，申请或加载了其余域名的资源。比方以后 app.a.com 申请了 file.b.com 的资源，就产生了跨域资源的加载。 浏览器在渲染以后页面时，校验网页申请的资源是否能够平安的在以后页面应用。比方： 是同站点下的资源，比方 app.a.com/logo.png，能够间接应用如果是同域名下的资源，比方 file.a.com/logo.png, 这时会校验文件的响应头，看有没有配置 Access-Control-Allow-* 相干的访问控制参数如果是 file.b.com/logo.png 同样也会去校验访问控制信息信息如果资源的访问控制信息不能外表资源能够在以后站点应用，就会产生跨域的问题，浏览器会禁止资源的加载和展现。也就是说跨域问题其实是浏览器对资源应用安全策略产生的，浏览器要保障站点拜访资源是平安，非法拜访的。 浏览器是否能够应用某个资源有两个限度： 以后站点是否容许应用其余站点，域名的资源站点能够配置是否容许拜访其余域名的资源，比方在站点配置一些安全策略 # COEP 跨域嵌入策略，会阻止页面加载任何未明确授予文档许可权的跨域资源（应用CORP或CORS）。Cross-Origin-Embedder-Policy: require-corp# COOP Cross-Origin-Opener-Policy: same-origin申请的资源是否能够在以后站点应用资源是否开启了跨域资源共享策略，决定资源在哪些站点能够被应用，个别解决跨域的时候，须要在资源的响应头中配置以下选项 # 跨域资源策略Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin# cross-origin 示意该资源被任何站点应用# 容许通过哪些办法拜访Access-Control-Allow-Methods: GET | POST | PUT | OPTIONS | HEAD# 容许哪些域名拜访， * 代表所有，一般来说不平安Access-Control-Allow-Origin: *什么是 SharedArrayBufferSharedArrayBuffer(以下简称 SAB) 是一个 javascript 对象，用于网站线程之间的内存数据共享，比方 worker。同样因为 WebAssembly 应用 worker 模仿了多线程，所以在这种状况下同样会应用到 SAB 做数据共享拜访。 为什么应用 SAB 会遇到跨域问题18年 spectre 曝光之前，曾经有不少网站应用了 SAB。因为 spectre 是 cpu 层面的破绽，不太可能通过cpu 降级去解决，因而过后所有浏览器间接禁用了 SAB，来避免 spectre 的旁路攻打。那么什么是 spectre 攻打，用艰深一点的话来说，就是 cpu 有一个机制，叫做预测机制，如果有一个恶意程序去查问一个没有权限的信息，操作系统会返回禁止的信息，自身来说这个逻辑当然没有问题。然而当恶意程序询问时，其实操作系统即便返回了禁止的信息，然而还是会因为预测机制会去执行正确答案的逻辑，会导致慢了一小段时间，比方几微秒，几毫米，这就被恶意程序留神到了，通过每隔一段时间一直去尝试询问，达到获取正确答案的成果。恶意程序能够通过 SAB 获取到其余页面的敏感信息。咱们都晓得 worker 在浏览器中有很大的限度，比方不能拜访 window, document 对象， SAB 是用来和主线程进行数据交换拜访的高效办法，也被大量利用，这就会导致 worker 是有方法通过 SAB 攻打获取到主线程的敏感信息。所以在 spectre 破绽曝出时，简直所有支流浏览器都默认敞开了 SAB 以应答这个破绽的攻打。 ...

带 credentials 的 CORS 申请Credentials 与 CORSCredentials(凭证) 能够是 cookies, authorization headers 或 TLS client certificates。CORS 申请默认不发送 Credentials。 如何让 CORS 申请发送 Credentials？如果要让带 credentials 的 CORS 申请胜利，前后端都须要配置。否则，即便服务器批准发送 Cookie，浏览器也不会发送。或者，服务器要求设置 Cookie，浏览器也不会解决。 Cookie 仍然遵循同源政策，只有用服务器域名设置的 Cookie 才会上传，其余域名的 Cookie 并不会上传配置后端配置：Access-Control-Allow-Credentials header;前端配置：XHR 配置 withCredentials 或 Fetch request 配置 credentials; Access-Control-Allow-Credentials 它的值是一个布尔值，示意是否容许发送 Cookie。默认状况下，Cookie 不包含在 CORS 申请之中。设为true，即示意服务器明确许可，Cookie 能够蕴含在申请中，一起发给服务器。如果服务器不要浏览器发送 Cookie，删除该字段即可。 Request.credentials credentials 是Request接口的只读属性，用于示意用户代理是否应该在跨域申请的状况下从其余域发送 cookies。有三个可选值： omit: 从不发送cookies。same-origin: 只有当URL与响应脚本同源才发送 cookies、 HTTP Basic authentication 等验证信息。include: 不论是不是跨域的申请, 总是发送申请资源域在本地的 cookies、 HTTP Basic authentication 等验证信息。XMLHttpRequest.withCredentials withCredentials是一个Boolean类型，如果是 true, 执行跨域申请时会带上 Credentials，否则不会携带。默认值是false。 ...

同源策略同源策略，它是由Netscape提出的一个驰名的安全策略。当初所有反对JavaScript 的浏览器都会应用这个策略来对脚本和申请进行校验，若不同源，则禁止应用。 同源的定义那如果判断是否同源？次要依据三个维度，域名，协定，端口三个都雷同才算同源。举个 ： 网站A网站B后果http://www.zhenai.comhttp://i...不同源，域名不同http://www.zhenai.comhttp://w...不同源，域名不同http://www.zhenai.comhttps://...不同源，协定不同http://www.zhenai.comhttp://w...不同源，端口不同(默认端口80) 同源策略的作用①无奈用js读取非同源的Cookie、LocalStorage 和 IndexDB这个次要是为了避免歹意网站通过js获取用户其余网站的cookie等用户信息。 ②无奈用js获取非同源的DOM避免歹意网站通过iframe获取页面dom，从而窃取页面的信息。 ③无奈用js发送非同源的AJAX申请避免歹意的申请攻打服务器窃取数据信息。 那是不是说非同源的申请就无奈实现呢？也不是，这就引出了咱们本文次要论述的解决跨域申请问题的办法。 jsonpjsonp能实现跨域是利用了img、script和link标签本身的跨域能力。咱们晓得当img或者script中的src是一个链接的时候，浏览器会申请这个链接获取资源，那么这个链接如果是跨域的，浏览器也会申请，从而达到了跨域申请的一个性能。 用法 var script = document.createElement('script');script.src = 'http://localhost:3000/api/test.do?a=1&b=2&callback=cb';$('body').append(script);function cb(res){ // do something console.log(res)}能够看到，咱们创立一个script标签，将src改成咱们要申请的接口，并将script增加在body中，那么当浏览器解析到这个script时，会想src对应的服务器发送一个get申请，并将参数带过来。而后当浏览器接管到服务端返回的数据，就会触发参数中callbak对应的回调函数cb，从而实现整个get申请。 长处简略粗犷 毛病①只反对get申请②须要后盾配合，将返回后果包装成callback(res)的模式 防备那如果黑客植入script脚本通过jsonp的形式对服务器进行攻打，怎么办？能够通过页面设置的内容平安协定csp进行防备。 cors跨域cors 是一个W3C规范,全称是"跨域资源共享"（Cross-origin resource sharing），它容许浏览器向跨源服务器发送XMLHttpRequest申请，从而克服了 AJAX 只能同源应用的限度cors 须要浏览器和服务器同时反对，整个 CORS通信过程，都是浏览器主动实现不须要用户参加，对于开发者来说，cors的代码和失常的 ajax 没有什么差异，浏览器一旦发现跨域申请，就会增加一些附加的头信息然而，cors不反对ie10及以下版本。 简略申请和简单申请浏览器将cors申请分为简略申请和简单申请。简略申请则间接发送申请到服务器，只申请一次。而简单申请在正式申请前都会有预检申请，在浏览器中都能看到有OPTIONS申请，用于向服务器申请权限信息的，须要申请两次。 那如何辨别是简略申请还是简单申请呢？ 简略申请简略申请必须要同时满足上面三个条件： 申请形式只能是：GET、POST、HEADHTTP申请头限度这几种字段：Accept、Accept-Language、Content-Language、Content-Type、Last-Event-IDContent-type只能取：application/x-www-form-urlencoded、multipart/form-data、text/plaincontent-type的类型类型形容application/json音讯主体是序列化后的 JSON 字符串application/x-www-form-urlencoded数据被编码为键值对。这是规范的编码格局multipart/form-data须要在表单中进行文件上传时，就须要应用该格局。常见的媒体格式是上传文件之时应用的text/plain数据以纯文本模式(text/json/xml/html)进行编码，其中不含任何控件或格局字符 application/json： 作用： 通知服务器申请的主题内容是json格局的字符串，服务器端会对json字符串进行解析，益处： 前端人员不须要关怀数据结构的复杂度，只有是规范的json格局就能提交胜利。application/x-www-form-urlencoded：是Jquery的Ajax申请默认形式 作用：在申请发送过程中会对数据进行序列化解决，以键值对模式？key1=value1&key2=value2的形式发送到服务器。益处： 所有浏览器都反对。简单申请不满足简略申请的条件，那么就是简单申请。简单申请会在正式申请发送之前，先发一个预检申请进行校验，校验通过后能力进行正式申请。举个浏览器当初要发送一个put的简单申请，那么在put申请发送之前，浏览器先发送一个options申请。options申请头信息： OPTIONS /cors HTTP/1.1Origin: localhost:3000Access-Control-Request-Method: PUT // 示意应用的什么HTTP申请办法Access-Control-Request-Headers: X-Custom-Header // 示意浏览器发送的自定义字段Host: localhost:3000Accept-Language: zh-CN,zh;q=0.9Connection: keep-aliveUser-Agent: Mozilla/5.0...服务器收到options申请当前，查看了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段当前，确认容许跨源申请，就能够做出回应options响应头信息 HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:39 GMTServer: Apache/2.0.61 (Unix)Access-Control-Allow-Origin: http://localhost:3000 // 示意http://localhost:3000能够拜访数据Access-Control-Allow-Methods: GET, POST, PUT Access-Control-Allow-Headers: X-Custom-Header Content-Type: text/html; charset=utf-8Content-Encoding: gzipContent-Length: 0Keep-Alive: timeout=2, max=100Connection: Keep-AliveContent-Type: text/plain当options申请通过之后收回正式的HTTP申请，假使options申请不通过，则服务器不容许此次拜访,从而抛出谬误 ...

浏览器中的HTTP申请XMLHttpRequestXHR对象用于与服务器交互。通过XMLHttpRequest能够在不刷新页面的状况下申请特定URL，获取数据。XMLHttpRequest在AJAX编程中被大量应用。 MDN文档 FetchFetch API提供了一个获取资源的接口（包含跨域申请） MDN文档 AJAXAsynchronous JavaScript And XML，是一种应用XMLHttpRequest技术构建更简单，动静的网页的编程实际。大部分的ajax其实就是对XMLHttpRequest的相干API进行封装，使其应用起来更加不便。 MDN文档 跨域跨域，顾名思义，逾越区域。大略意思为拜访的网站申请非同源资源。 因为安全性等问题，浏览器自带同源策略，所谓同源是指域名，协定，端口均雷同。当拜访的网站须要申请非同源资源时，浏览器将回绝这些非同源申请。在这种状况下，咱们须要解决浏览器跨域时拒绝请求非同源资源的限度。 当浏览器呈现跨域时，那就不可避免的引出两个要害的概念了。简略申请和非简略申请。 当跨域产生时，非简略申请会在真正向服务端发送申请前进行预检申请（OPTIONS），。 简略申请1、条件定义：若申请满足以下所有的条件，则申请可视为简略申请。 应用下列办法之一：GETHEADPOST申请首部字段不得超出以下汇合AcceptAccept-LanguageContent-LanguageConent-Type：text/plain || multipart/form-data || application/x-www-form-urlencodedDPRDownlinkSave-DataViewport-WidthWidth申请中的任意XMLHttpRequestUpload 对象均没有注册任何事件监听器申请中没有应用 ReadableStream 对象非简略申请1、条件定义：若申请满足下列任一条件时，即应首先发送预检申请（options）。 应用了上面的任一办法：PUTDELETECONNECTOPTIONSTRACEPATCH设置了额定的申请首部字段（除去以下汇合中的）AcceptAccept-LanguageContent-LanguageConent-Type：text/plain || multipart/form-data || application/x-www-form-urlencodedDPRDownlinkSave-DataViewport-WidthWidth申请中的XMLHttpRequestUpload 对象注册了任意多个事件监听器申请中应用了ReadableStream对象解决跨域的计划jsonpJSON with Padding，是JSON的一种应用模式，能够让网页从别的网域获取材料。因为同源策略，一般来说位于server1.example.com的网页无奈与不是server1.example.com的服务器沟通，而HTML的<script>元素是一个例外。利用<script>元素的这个凋谢策略，网页就能够实现跨域获取后端接口数据。 因为应用script标签的src属性，因而只反对get办法。 当应用JSONP这种计划时，前后端都要有绝对应的写法。 大抵流程就是，前端通过<script>标签的src属性向后盾接口发动申请（只反对GET申请），并且传递参数callback='response'，与此同时，前端必须定义函数response(responseData)，这是用来解决接口返回数据后一些操作。 当接口收到申请，返回数据格式为response(responseData)。这样，以后端承受到数据response(responseData)，就刚好执行了咱们曾经定义好的response(...) 当报错如下时：起因是：后端接口没有返回callback(...) 维基百科 JSONP的原理和实现 CORSCross Origin Resource Sharing，跨域资源共享，由一系列传输的HTTP头组成，这些HTTP头决定浏览器是否阻止前端JavaScript代码获取跨域申请的响应。 MDN文档 1、Access-Control-Allow-Origin：批示申请的资源能共享给哪些域 2、Access-Control-Allow-Credentials：批示当申请的凭证标记为true时，是否响应该申请 3、Access-Control-Allow-Headers：用在对预申请的响应中，哪些HTTP办法容许拜访申请的资源 4、Access-Control-Expose-Headers：批示哪些HTTP头的名称能在响应中列出 5、Access-Control-Max-Age：批示预申请的后果能被缓存多久 6、Access-Control-Request-Headers：用于发动一个预申请，告知服务器正式申请会应用哪些HTTP头 7、Access-Control-Request-Method：用于发动一个预申请，告知服务器正式申请会应用哪一种HTTP申请办法 8、Origin：批示获取资源的申请是从什么域发动的 koa2中接口容许跨域响应，响应头部字段设置如下： ctx.set('Access-Control-Allow-Origin', '*');ctx.set('Access-Control-Allow-Methods', 'POST, GET, OPTIONS, DELETE, PUT');ctx.set('Access-Control-Allow-Headers', 'X-Requested-With, User-Agent, Referer, Content-Type, Cache-Control,accesstoken'); ctx.set('Access-Control-Max-Age', '86400');ctx.set('Access-Control-Allow-Credentials', 'true');注意事项： 若增加了自定义的Header字段，必须将这个字段名增加到服务端响应头部Access-Control-Allow-Headers中，不然会报错。 我的项目踩坑：在接口响应中增加了以上容许跨域响应的头部字段，然而在开发中还报了跨域的谬误（Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request）,报错的大抵意思是预检申请禁止重定向。通过排查，发现是服务端nginx做了HTTP到HTTPS的重定向设置，而我恰好是以http+ip地址的模式发动申请的，那么申请就被重定向到https了，然而，浏览器发动的预检申请是禁止重定向的，因而报错了。解决方案就是将申请地址改为https+域名的模式，这样预检申请就不会重定向了。 ...

背景晚期为了防止 CSRF（跨站申请伪造） 攻打，浏览器引入了 “同源策略” 机制。如果两个 URL 的协定，主机名（域名/IP），端口号统一，则视为这两个 URL “同源”，属于同一个 “域”，否则视为 “非同源”，即 “跨域”。浏览器会被动拦挡跨域的 AJAX 申请，以躲避平安危险。 “同源策略” 诚然晋升了申请的安全性，但有时咱们须要跨域申请其余域名下的资源，例如在业务域名下申请 COS 的 API 接口，或者读取 COS 存储桶中文件的内容，进行一些逻辑解决。 浏览器反对一种跨域的拜访验证的机制，即 CORS（Cross-Origin Resource Sharing 跨源资源共享）。该机制容许服务端通过返回特定的 HTTP 头部来告知浏览器是否拦挡跨域申请。 COS 反对用户在存储桶中配置 “跨域拜访 CORS” 规定，以此放行一些非法的跨域申请。 业务场景上面咱们以 博客网站开发 为例，带您理解如何在 COS 配置 CORS 规定。 用户正在开发一个博客网站，为此他将一批 markdown 文件上传到 COS，对每个 markdown 文件设置了自定义头部 x-cos-meta-keywords 示意该文章的关键词，并将文件权限设置为私有读公有写。 网站的前端 JS 脚本通过浏览器向 COS 发动 AJAX 申请，读取响应的内容以及头部信息，将内容转换为 HTML 文本，解析 x-cos-meta-keywords 中蕴含的关键词，别离挂载到页面对应的 DOM 节点下，其申请过程如下图所示： 用户网站的地址是 http://example.com，Markdown 文件的地址是 https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com/test.md 很显然，这是在 http://example.com 下对 https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com 发动申请，波及跨域。 ...

前后端拆散我的项目跨域问题是不可避免的。通常状况下前端由React、Vue等框架编写，通过ajax申请服务端API，传输数据用json格局。 那么为什么有跨域的问题呢？解决跨域问题有哪些形式？搞清楚这两个问题咱们须要理解一下什么是同源策略。 浏览器的同源策略 同源策略（Same origin policy）是一种平安约定，是所有支流浏览器最外围也是最根本的平安性能之一。同源策略规定：不同域的客户端脚本在没有明确受权的状况下，不能申请对方的资源。同源指的是：域名、协定、端口均雷同。 比方咱们拜访一个网站,那么这个页面申请如下地址得状况是这样的： 另外，同源策略又分如下两种状况： DOM同源策略：禁止对不同源的页面DOM进行操作，次要避免iframe的状况。比方iframe标签里放一个支付宝付款的页面，如果没有同源策略，那么钓鱼网站除了域名不同，其余的则能够和支付宝的网站截然不同。XMLHttpRequest同源策略：禁止应用XHR对象向不同源的服务器发动http申请。比方网站记录了银行的cookie，这个时候你拜访了歹意网站，黑客拿到你的cookie，再通过ajax申请之前的银行网站，便能够轻易的拿到你的银行信息。 所以，正是因为有了同源策略，大家的网络环境才绝对的平安一些。 跨域问题的解决办法 理解了同源策略，就晓得为什么会有跨域问题的产生了，都是为了平安。然而理论研发中，大家还是须要跨域去拜访资源。典型的利用场景就是前后端拆散的我的项目了。那么咱们如何去解决跨域问题呢？ CORS-跨域资源共享 CORS是一种W3C规范，定义了当产生跨域问题的时候，客户端与服务端如何通信解决跨域问题。实际上就是前后端约定好定义一些自定义的http申请头，让客户端发动申请的时候可能让服务端辨认进去该申请是过还是不过。 浏览器将CORS申请分为简略申请和非简略申请： 简略申请 简略申请必须满足以下两个条件： 申请形式必须是HEAD、GET、POST三种办法之一。Http申请头必须只能是：Accept、Accept-Lanuage、Content-Lanuage、Last-Event-ID、Content-Type，其中Content-Type只限于三个值 application/x-www-form-urlencoded、multipart/form-data、text/plain。非简略申请 不满足简略申请条件的就是非简略申请。针对非简略申请，浏览器会发动预检申请。预检申请的意思是当浏览器查看到你的页面含有跨域申请的时候，会发送一个OPTIONS申请给对应的服务器，以检测服务器是否容许以后域名的跨域申请。如果服务端容许该域名申请，则返回204或200状态码，浏览器接管到容许申请时候再持续发送对应的GET/POST/PUT/DELETE申请。同时服务器端也会告知浏览器预检申请的缓存时长是多少，在这个工夫范畴内，浏览器不会再次发动预检申请。 原理基本上就是下面说的这些，理论业务中咱们如何通过配置来解决跨域问题呢？基本上常见的就是三种形式： nginx配置 通常咱们在nginx减少如下配置即可解决跨域问题： 用nginx这种形式是最舒服的，不须要客户端和服务端多做其余工作，对代码无入侵。 jsonp 因为script标签是不受浏览器同源策略的影响，容许跨域申请资源（咱们的每一个页面都援用了大量第三方js文件）。所以能够利用动态创建script标签，通过src属性发动跨域申请，这就是jsonp的原理。然而jsonp只反对GET申请，所以并不是一种好的形式。 服务端代码管制 能够在服务端减少对跨域申请的反对： 这种形式相当于全局过滤器，对所有申请都过滤一遍。 以上三种形式都能够肯定水平上解决跨域问题，然而nginx配置和服务端管制不能同时存在，否则会报“Access-Control-Allow-Origin Not Allow Multiple value”的谬误。集体比拟举荐nginx配置的形式，一劳永逸，不须要每个web我的项目都去编写跨域的代码。 大家在工作中有没有遇到过跨域问题呢？都是怎么解决的？欢送评论区交换探讨，独特学习~ 结尾本期就分享到这里，我是小编南风吹，专一分享好玩乏味、离奇、实用的开源我的项目及开发者工具、学习资源！心愿能与大家独特学习交换,欢送关注我的公众号【Github导航站】。 往期举荐太漂亮了！有了3款开源图标库，不必再去求设计师了 10个相见恨晚的vue.js库！用好了，事倍功半！ 太及时了！13个Spring Boot练手我的项目,用好了，升职涨薪不必愁 程序员接私活必备后盾框架，不必反复造轮子，网友：太好用了！ 还在从头到尾撸我的项目？这6个SpringBoot我的项目用好了，事倍功半！ 「00后缩写黑话翻译器」登上GitHub热榜，中年网民终于能看懂年轻人的awsl

1、http-proxy-middleware应用办法在src目录下创立setupProxy.js文件 const proxy = require("http-proxy-middleware");// app能够了解为一个express实例module.exports = function (app) { app.use( proxy(['/mock/1241', '/mock/1105'], { target: "http://10.118.71.83:3000/", // 指标服务器 changeOrigin: true // 默认false，是否须要扭转原始主机头为指标URL，是否进行代理 }), );}http-proxy-middleware会作为target的反向代理服务器，承受http://localhost:3000/mock/1241/xxx申请。 一些罕用参数阐明： // proxy 中间件的选择项var config= { target: 'http://www.example.org', // 指标服务器 host changeOrigin: true, // 默认false，是否须要扭转原始主机头为指标URL ws: true, // 是否代理websockets pathRewrite: { '^/api/old-path': '/api/new-path', // 重写申请，比方咱们源拜访的是api/old-path，那么申请会被解析为/api/new-path '^/api/remove/path': '/path' // 同上 }, router: { // 如果申请主机 == 'dev.localhost:3000', // 重写指标服务器 'http://www.example.org' 为 'http://localhost:8000' 'dev.localhost:3000' : 'http://localhost:8000' }};target：用于设置指标服务器host。changeOrigin：默认false，是否须要扭转原始主机头为指标URL。ws：设置是否代理websockets。pathRewrite：重写指标url门路。router：重写指定申请转发指标具体能够参考：https://www.cnblogs.com/zhaow... ...

京淘前台我的项目搭建京淘架构图设计 JT-WEB我的项目创立创立JT-WEB服务器 增加继承/依赖/插件<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><!--我的项目坐标--><modelVersion>4.0.0</modelVersion><artifactId>jt-web</artifactId><!--应用模板打jar包 不应用模板打war包--><packaging>war</packaging><!--父级工程--><parent><artifactId>jt2007</artifactId><groupId>com.jt</groupId><version>1.0-SNAPSHOT</version></parent><!--增加依赖项--><dependencies><dependency><groupId>com.jt</groupId><artifactId>jt-common</artifactId><version>1.0-SNAPSHOT</version></dependency></dependencies><!--增加maven插件--><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin></plugins></build></project>导入动态资源文件阐明:将课前材料中的文件src目录导入到jt-web中 对于主启动类阐明阐明:jt-web服务器启动时会加载数据源的自动化配置,然而web服务器没有配置数据源,所以报错.启动类上增加数据源启动. 配置工作目录 域名反向代理需要: 要求用户通过http://www.jt.com 拜访localhost:8092服务器. 改hosts文件 批改Nginx配置文件#配置前台服务器 server { listen 80; server_name www.jt.com; location / { proxy_pass http://localhost:8092; } }批改之后,重启nginx服务器 页面成果展示 谷歌浏览器禁用HTTPS键入地址:chrome://net-internals/#hsts：批改实现之后,先清空缓存之后重启浏览器 对于伪动态的阐明业务阐明问题1: 京东的商品有很多,如果都采纳动态页面的模式为用户展示数据,如果有100万的商品,那么就须要100万个商品的xxx.html页面. 问:京东是这么做的吗???实现规定:应该动静获取商品的ID号.之后查询数据库,而后调整指定的页面,将数据进行填充即可. 问题2: 为什么京东采纳.html结尾的申请展示商品呢?答案: 采纳.html结尾的页面,更加容易被搜索引擎收录,进步网站的曝光率. 搜索引擎工作原理工作原理外围: 倒排索引机制. 依据关键字检索文章的地位. 伪动态思维伪动态是绝对实在动态来讲的，通常咱们为了加强搜索引擎的敌对面，都将文章内容生成动态页面，然而有的敌人为了实时的显示一些信息。或者还想使用动静脚本解决一些问题。不能用动态的形式来展现网站内容。然而这就损失了对搜索引擎的敌对面。怎么样在两者之间找个两头办法呢，这就产生了伪动态技术。伪动态技术是指展现进去的是以html一类的动态页面模式，但其实是用ASP一类的动静脚本来解决的。 开启后缀类型匹配阐明: 因为京东商城的商品展示时通过 url:https://item.jd.com/10021377498920.html,京东的拜访是依据.html进行拦挡,之后通过restFul构造动静获取商品的ID号,之后查询数据库进行的回显.所以须要对后缀进行拦挡.有了如下的配置. package com.jt.config;import org.springframework.context.annotation.Configuration;import org.springframework.web.servlet.config.annotation.PathMatchConfigurer;import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;@Configurationpublic class MvcConfigurer implements WebMvcConfigurer{ //开启匹配后缀型配置 @Override public void configurePathMatch(PathMatchConfigurer configurer) { configurer.setUseSuffixPatternMatch(true); }}URL地址小结: http://www.jt.com/index 该申请会被Controller进行拦挡.http://www.jt.com/index.html 该申请默认条件下示意获取动态资源文件.不会被拦挡.个别条件下:Controller只拦挡前缀类型的申请. 如果须要拦挡后缀类型的申请须要独自配置. 登录注册页面跳转实现通用页面跳转url1: http://www.jt.com/user/login.html 跳转页面 login.jspurl2: http://www.jt.com/user/register.html 跳转页面 register.jsp ...

服务器与服务器之间发动的申请时不存在跨域的说法的，跨域是浏览器同源策略引起的，即：从某一个域申请其余域的各类资源，其中只有两个地址的域名、端口以及协定有不同的中央就会视为跨域，跨域资源无奈间接获取，这是浏览器针对javascript发动的平安限度。ng个别能够通过反向代理或者access等配置解决跨域。反向代理：是将被拜访的服务端地址反向代理至以后ng的域名地址下，来解决跨域的问题。access配置：通过对response加上容许跨域的头字段，浏览器收到response之后判断可跨域从而拜访胜利。 add_header Access-Control-Allow-Methods *; # 预检命令的缓存，如果不缓存每次会发送两次申请 add_header Access-Control-Max-Age 3600; # 带cookie申请须要加上这个字段，并设置为true add_header Access-Control-Allow-Credentials true; # 示意容许这个域跨域调用（客户端发送申请的域名和端口） # $http_origin动静获取申请客户端申请的域 不必*的起因是带cookie的申请不反对*号 add_header Access-Control-Allow-Origin $http_origin; # 示意申请头的字段 动静获取 add_header Access-Control-Allow-Headers $http_access_control_request_headers;