什么是跨域？一次性带你理解透

最新推荐文章于 2023-12-29 15:35:24 发布
最新推荐文章于 2023-12-29 15:35:24 发布
阅读量422 收藏
点赞数

跨域这两个字就像一块狗皮膏药一样黏在每一个前端开发者身上，无论你在工作上或者面试中无可避免会遇到这个问题。为了应付面试，我每次都随便背几个方案，也不知道为什么要这样干，反正面完就可以扔了，我想工作上也不会用到那么多乱七八糟的方案。到了真正工作，开发环境有webpack-dev-server搞定，上线了服务端的大佬们也会配好，配了什么我不管，反正不会跨域就是了。日子也就这么混过去了，终于有一天，我觉得不能再继续这样混下去了，我一定要彻底搞懂这个东西！于是就有了这篇文章。

要掌握跨域，首先要知道为什么会有跨域这个问题出现

确实，我们这种搬砖工人就是为了混口饭吃嘛，好好的调个接口告诉我跨域了，这种阻碍我们轻松搬砖的事情真恶心！为什么会跨域？是谁在搞事情？为了找到这个问题的始作俑者，请点击：浏览器的同源策略。

这么官方的东西真难懂，没关系，至少你知道了，因为浏览器的同源策略导致了跨域，就是浏览器在搞事情。

所以，浏览器为什么要搞事情？就是不想给好日子我们过？对于这样的质问，浏览器甩锅道：“同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。”

这么官方的话术真难懂，没关系，至少你知道了，似乎这是个安全机制。

所以，究竟为什么需要这样的安全机制？这样的安全机制解决了什么问题？别急，让我们继续研究下去。

没有同源策略限制的两大危险场景

据我了解，浏览器是从两个方面去做这个同源策略的，一是针对接口的请求，二是针对Dom的查询。试想一下没有这样的限制上述两种动作有什么危险。

没有同源策略限制的接口请求

有一个小小的东西叫cookie大家应该知道，一般用来处理登录等场景，目的是让服务端知道谁发出的这次请求。如果你请求了接口进行登录，服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中，服务端就能知道这个用户已经登录过了。知道这个之后，我们来看场景：

  1. 你准备去清空你的购物车，于是打开了买买买网站www.maimaimai.com，然后登录成功，一看，购物车东西这么少，不行，还得买多点。
  2. 你在看有什么东西买的过程中，你的好基友发给你一个链接www.nidongde.com，一脸yin笑地跟你说：“你懂的”，你毫不犹豫打开了。
  3. 你饶有兴致地浏览着www.nidongde.com，谁知这个网站暗地里做了些不可描述的事情！由于没有同源策略的限制，它向www.maimaimai.com发起了请求！聪明的你一定想到上面的话“服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中”，这样一来，这个不法网站就相当于登录了你的账号，可以为所欲为了！如果这不是一个买买买账号，而是你的银行账号，那……

这就是传说中的CSRF攻击。

看了这波CSRF攻击我在想，即使有了同源策略限制，但cookie是明文的，还不是一样能拿下来。于是我看了一些cookie相关的文章：聊一聊 cookie、Cookie/Session的机制与安全，知道了服务端可以设置httpOnly，使得前端无法操作cookie，如果没有这样的设置，像XSS攻击就可以去获取到cookie（Web安全测试之XSS）；设置secure，则保证在https的加密通信中传输以防截获。

没有同源策略限制的Dom查询

  1. 有一天你刚睡醒，收到一封邮件，说是你的银行账号有风险，赶紧点进www.yinghang.com改密码。你吓尿了，赶紧点进去，还是熟悉的银行登录界面，你果断输入你的账号密码，登录进去看看钱有没有少了。
  2. 睡眼朦胧的你没看清楚，平时访问的银行网站是www.yinhang.com，而现在访问的是www.yinghang.com，这个钓鱼网站做了什么呢？
  1. // HTML
  2. <iframe name="yinhang" src="www.yinhang.com"></iframe>
  3. // JS
  4. // 由于没有同源策略的限制，钓鱼网站可以直接拿到别的网站的Dom
  5. const iframe = window.frames['yinhang']
  6. const node = iframe.document.getElementById('你输入账号密码的Input')
  7. console.log(`拿到了这个${node}，我还拿不到你刚刚输入的账号密码吗`)

由此我们知道，同源策略确实能规避一些危险，不是说有了同源策略就安全，只是说同源策略是一种浏览器最基本的安全机制，毕竟能提高一点攻击的成本。其实没有刺不穿的盾，只是攻击的成本和攻击成功后获得的利益成不成正比。

跨域正确的打开方式

经过对同源策略的了解，我们应该要消除对浏览器的误解，同源策略是浏览器做的一件好事，是用来防御来自邪门歪道的攻击，但总不能为了不让坏人进门而把全部人都拒之门外吧。没错，我们这种正人君子只要打开方式正确，就应该可以跨域。

下面将一个个演示正确打开方式，但在此之前，有些准备工作要做。为了本地演示跨域，我们需要：

  1. 随便跑起一份前端代码（以下前端是随便跑起来的vue），地址是http://localhost:9099。
  2. 随便跑起一份后端代码（以下后端是随便跑起来的node koa2），地址是http://localhost:9971。

同源策略限制下接口请求的正确打开方式

1.JSONP

在HTML标签里，一些标签比如、img这样的获取资源的标签是没有跨域限制的，利用这一点，我们可以这样干。

后端写个小接口：

  1. // 处理成功失败返回格式的工具
  2. const {successBody} = require('../utli')
  3. class CrossDomain {
  4. static async jsonp (ctx) {
  5. // 前端传过来的参数
  6. const query = ctx.request.query
  7. // 设置一个cookies
  8. ctx.cookies.set('tokenId', '1')
  9. // query.cb是前后端约定的方法名字，其实就是后端返回一个直接执行的方法给前端，由于前端是用标签发起的请求，所以返回了这个方法后相当于立马执行，并且把要返回的数据放在方法的参数里。
  10. ctx.body = `${query.cb}(${JSON.stringify(successBody({msg: query.msg}, 'success'))})`
  11. }
  12. }
  13. module.exports = CrossDomain

简单版前端：

  1. <!DOCTYPE html>
  2. <html>
  3. <head>
  4. <meta charset="utf-8">
  5. </head>
  6. <body>
  7. < type='text/java'>
  8. // 后端返回直接执行的方法，相当于执行这个方法，由于后端把返回的数据放在方法的参数里，所以这里能拿到res。
  9. window.jsonpCb = function (res) {
  10. console.log(res)
  11. }
  12. </>
  13. < src='http://localhost:9871/api/jsonp?msg=helloJsonp&cb=jsonpCb' type='text/java'></>
  14. </body>
  15. </html>

简单封装一下前端这个套路：

  1. /**
  2. * JSONP请求工具
  3. * @param url 请求的地址
  4. * @param data 请求的参数
  5. * @returns {Promise<any>}
  6. */
  7. const request = ({url, data}) => {
  8. return new Promise((resolve, reject) => {
  9. // 处理传参成xx=yy&aa=bb的形式
  10. const handleData = (data) => {
  11. const keys = Object.keys(data)
  12. const keysLen = keys.length
  13. return keys.reduce((pre, cur, index) => {
  14. const value = data[cur]
  15. const flag = index !== keysLen - 1 ? '&' : ''
  16. return `${pre}${cur}=${value}${flag}`
  17. }, '')
  18. }
  19. // 动态创建标签
  20. const = document.('')
  21. // 接口返回的数据获取
  22. window.jsonpCb = (res) => {
  23. document.body.removeChild()
  24. delete window.jsonpCb
  25. resolve(res)
  26. }
  27. .src = `${url}?${handleData(data)}&cb=jsonpCb`
  28. document.body.()
  29. })
  30. }
  31. // 使用方式
  32. request({
  33. url: 'http://localhost:9871/api/jsonp',
  34. data: {
  35. // 传参
  36. msg: 'helloJsonp'
  37. }
  38. }).then(res => {
  39. console.log(res)
  40. })

2.空iframe加form

细心的朋友可能发现，JSONP只能发GET请求，因为本质上加载资源就是GET，那么如果要发POST请求怎么办呢？

后端写个小接口：

  1. // 处理成功失败返回格式的工具
  2. const {successBody} = require('../utli')
  3. class CrossDomain {
  4. static async iframePost (ctx) {
  5. let postData = ctx.request.body
  6. console.log(postData)
  7. ctx.body = successBody({postData: postData}, 'success')
  8. }
  9. }
  10. module.exports = CrossDomain

前端：

  1. const requestPost = ({url, data}) => {
  2. // 首先创建一个用来发送数据的iframe.
  3. const iframe = document.('iframe')
  4. iframe.name = 'iframePost'
  5. iframe.style.display = 'none'
  6. document.body.(iframe)
  7. const form = document.('form')
  8. const node = document.('input')
  9. // 注册iframe的load事件处理程序,如果你需要在响应返回时执行一些操作的话.
  10. iframe.addEventListener('load', function () {
  11. console.log('post success')
  12. })
  13.  
  14. form.action = url
  15. // 在指定的iframe中执行form
  16. form.target = iframe.name
  17. form.method = 'post'
  18. for (let name in data) {
  19. node.name = name
  20. node.value = data[name].toString()
  21. form.(node.cloneNode())
  22. }
  23. // 表单元素需要添加到主文档中.
  24. form.style.display = 'none'
  25. document.body.(form)
  26. form.submit()
  27.  
  28. // 表单提交后,就可以删除这个表单,不影响下次的数据发送.
  29. document.body.removeChild(form)
  30. }
  31. // 使用方式
  32. requestPost({
  33. url: 'http://localhost:9871/api/iframePost',
  34. data: {
  35. msg: 'helloIframePost'
  36. }
  37. })

3.CORS

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）跨域资源共享 CORS 详解。看名字就知道这是处理跨域问题的标准做法。CORS有两种请求，简单请求和非简单请求。

这里引用上面链接阮一峰老师的文章说明一下简单请求和非简单请求。

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

只要同时满足以下两大条件，就属于简单请求。

（1）请求方法是以下三种方法之一：

  • HEAD
  • GET
  • POST

（2）HTTP的头信息不超出以下几种字段：

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

1、简单请求

后端：

  1. // 处理成功失败返回格式的工具
  2. const {successBody} = require('../utli')
  3. class CrossDomain {
  4. static async cors (ctx) {
  5. const query = ctx.request.query
  6. // *时cookie不会在http请求中带上
  7. ctx.set('Access-Control-Allow-Origin', '*')
  8. ctx.cookies.set('tokenId', '2')
  9. ctx.body = successBody({msg: query.msg}, 'success')
  10. }
  11. }
  12. module.exports = CrossDomain

前端什么也不用干，就是正常发请求就可以，如果需要带cookie的话，前后端都要设置一下，下面那个非简单请求例子会看到。

  1. fetch(`http://localhost:9871/api/cors?msg=helloCors`).then(res => {
  2. console.log(res)
  3. })

2、非简单请求非简单请求会发出一次预检测请求，返回码是204，预检测通过才会真正发出请求，这才返回200。这里通过前端发请求的时候增加一个额外的headers来触发非简单请求。

后端：

  1. // 处理成功失败返回格式的工具
  2. const {successBody} = require('../utli')
  3. class CrossDomain {
  4. static async cors (ctx) {
  5. const query = ctx.request.query
  6. // 如果需要http请求中带上cookie，需要前后端都设置credentials，且后端设置指定的origin
  7. ctx.set('Access-Control-Allow-Origin', 'http://localhost:9099')
  8. ctx.set('Access-Control-Allow-Credentials', true)
  9. // 非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）
  10. // 这种情况下除了设置origin，还需要设置Access-Control-Request-Method以及Access-Control-Request-Headers
  11. ctx.set('Access-Control-Request-Method', 'PUT,POST,GET,DELETE,OPTIONS')
  12. ctx.set('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept, t')
  13. ctx.cookies.set('tokenId', '2')
  14.  
  15. ctx.body = successBody({msg: query.msg}, 'success')
  16. }
  17. }
  18. module.exports = CrossDomain

一个接口就要写这么多代码，如果想所有接口都统一处理，有什么更优雅的方式呢？见下面的koa2-cors。

  1. const path = require('path')
  2. const Koa = require('koa')
  3. const koaStatic = require('koa-static')
  4. const bodyParser = require('koa-bodyparser')
  5. const router = require('./router')
  6. const cors = require('koa2-cors')
  7. const app = new Koa()
  8. const port = 9871
  9. app.use(bodyParser())
  10. // 处理静态资源 这里是前端build好之后的目录
  11. app.use(koaStatic(
  12. path.resolve(__dirname, '../dist')
  13. ))
  14. // 处理cors
  15. app.use(cors({
  16. origin: function (ctx) {
  17. return 'http://localhost:9099'
  18. },
  19. credentials: true,
  20. allowMethods: ['GET', 'POST', 'DELETE'],
  21. allowHeaders: ['t', 'Content-Type']
  22. }))
  23. // 路由
  24. app.use(router.routes()).use(router.allowedMethods())
  25. // 监听端口
  26. app.listen(9871)
  27. console.log(`[demo] start-quick is starting at port ${port}`)

前端：

  1. fetch(`http://localhost:9871/api/cors?msg=helloCors`, {
  2. // 需要带上cookie
  3. credentials: 'include',
  4. // 这里添加额外的headers来触发非简单请求
  5. headers: {
  6. 't': 'extra headers'
  7. }
  8. }).then(res => {
  9. console.log(res)
  10. })

4.代理

想一下，如果我们请求的时候还是用前端的域名，然后有个东西帮我们把这个请求转发到真正的后端域名上，不就避免跨域了吗？这时候，Nginx出场了。

Nginx配置：

  1. server{
  2. # 监听9099端口
  3. listen 9099;
  4. # 域名是localhost
  5. server_name localhost;
  6. #凡是localhost:9099/api这个样子的，都转发到真正的服务端地址http://localhost:9871
  7. location ^~ /api {
  8. proxy_pass http://localhost:9871;
  9. }
  10. }

前端就不用干什么事情了，除了写接口，也没后端什么事情了。

  1. // 请求的时候直接用回前端这边的域名http://localhost:9099，这就不会跨域，然后Nginx监听到凡是localhost:9099/api这个样子的，都转发到真正的服务端地址http://localhost:9871
  2. fetch('http://localhost:9099/api/iframePost', {
  3. method: 'POST',
  4. headers: {
  5. 'Accept': 'application/json',
  6. 'Content-Type': 'application/json'
  7. },
  8. body: JSON.stringify({
  9. msg: 'helloIframePost'
  10. })
  11. })

Nginx转发的方式似乎很方便！但这种使用也是看场景的，如果后端接口是一个公共的API，比如一些公共服务获取天气什么的，前端调用的时候总不能让运维去配置一下Nginx，如果兼容性没问题（IE 10或者以上），CROS才是更通用的做法吧。

同源策略限制下Dom查询的正确打开方式

1.postMessage

window.postMessage()是HTML5的一个接口，专注实现不同窗口不同页面的跨域通讯。

为了演示方便，我们将hosts改一下：127.0.0.1 crossDomain.com，现在访问域名crossDomain.com就等于访问127.0.0.1。

这里是http://localhost:9099/#/crossDomain，发消息方：

  1. <template>
  2. <div>
  3. <button @click="postMessage">给http://crossDomain.com:9099发消息</button>
  4. <iframe name="crossDomainIframe" src="http://crossdomain.com:9099"></iframe>
  5. </div>
  6. </template>
  7.  
  8. <>
  9. export default {
  10. mounted () {
  11. window.addEventListener('message', (e) => {
  12. // 这里一定要对来源做校验
  13. if (e.origin === 'http://crossdomain.com:9099') {
  14. // 来自http://crossdomain.com:9099的结果回复
  15. console.log(e.data)
  16. }
  17. })
  18. },
  19. methods: {
  20. // 向http://crossdomain.com:9099发消息
  21. postMessage () {
  22. const iframe = window.frames['crossDomainIframe']
  23. iframe.postMessage('我是[http://localhost:9099], 麻烦你查一下你那边有没有id为app的Dom', 'http://crossdomain.com:9099')
  24. }
  25. }
  26. }
  27. </>

这里是http://crossdomain.com:9099，接收消息方：

  1. <template>
  2. <div>
  3. 我是http://crossdomain.com:9099
  4. </div>
  5. </template>
  6.  
  7. <>
  8. export default {
  9. mounted () {
  10. window.addEventListener('message', (e) => {
  11. // 这里一定要对来源做校验
  12. if (e.origin === 'http://localhost:9099') {
  13. // http://localhost:9099发来的信息
  14. console.log(e.data)
  15. // e.source可以是回信的对象，其实就是http://localhost:9099窗口对象(window)的引用
  16. // e.origin可以作为targetOrigin
  17. e.source.postMessage(`我是[http://crossdomain.com:9099]，我知道了兄弟，这就是你想知道的结果：${document.getElementById('app') ? '有id为app的Dom' : '没有id为app的Dom'}`, e.origin);
  18. }
  19. })
  20. }
  21. }
  22. </>

结果可以看到：

2.document.domain

这种方式只适合主域名相同，但子域名不同的iframe跨域。

比如主域名是http://crossdomain.com:9099，子域名是http://child.crossdomain.com:9099，这种情况下给两个页面指定一下document.domain即document.domain = crossdomain.com就可以访问各自的window对象了。

3.canvas操作图片的跨域问题

这个应该是一个比较冷门的跨域问题，张大神已经写过了我就不再班门弄斧了：解决canvas图片getImageData,toDataURL跨域问题

转载http://www.sohu.com/a/241967861_661296

星夜蓝羽
关注
大语言模型应用指南：什么是提示工程
AI天才研究院
06-30 254
大语言模型应用指南：什么是提示工程 作者：禅与计算机程序设计艺术 / Zen and the Art of Computer Programming 关键词：提示工程（Prompt Engineering）、语言模型、NLP、自然语言处理、API调用 1. 背景介绍
通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core? .Net Web开发技术栈...
07-02 2086
通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core? 什么是.NET？什么是.NET Framework?本文将从上往下，循序渐进的介绍一系列相关.NET的概念，先从类型系统开始讲起，我将通过跨语言操作这个例子来逐渐引入一系列.NET的相关概念，这主要包括：CLS、CTS(CLI)、FCL、Windows下CLR的相关核心组成、Wind...
记录一下跨域的问题。
w83761456的专栏
07-28 1248
跨域的理解与实现2010-05-25域(Domain)是Windows网络中独立运行的单位，域之间相互访问则需要建立信任关系(即Trust Relation)。信任关系是连接在域与域之间的桥梁。当一个域与其他域建立了信任关系后，2个域之间不但可以按需要相互进行管理，还可以跨网分配
跨域的简介与解决方案
baocuan8515的博客
07-19 119
一、什么是同源？ 同源是指域名、协议和端口均相同。 二、什么是跨域？ 跨域是指一个域下的文档或脚本试图去请求另一个域下的资源（只要域名、协议和端口有任一个不同，就被当作是跨域） JavaScript 出于安全方面的考虑，不允许跨域调用其它页面的对象 几种常见场景： 不同文件：www.abc.com/index.html 调用 www.abc.com/serv...
跨域的简单理解
smallerha的博客
06-06 355
跨域是浏览器的一个特性，就是浏览器从一个“域”向另一个“域”的服务器发出请求，来访问另一个“域”上的资源。但是，由于这样请求的文件可能会被恶意攻击，所以浏览器就不允许直接访问另一个“域”上的资源了，只能访问同一个“域”上的资源，这个就是“同源策略”。而同源策略指的是“协议、域名、端口号”一致。同源策略限制以下几种行为： 1.Cookie、LocalStorage和indexDB无法读取 2.DOM节点无法读取和设置 3.AJAX请求不能发送 同源策略主要是来防止CSRF攻击（CSRF攻击是指利用用户的登陆状
跨域的简单介绍
gx0904的博客
03-06 466
一、跨域的简单介绍 跨域就指着协议，域名，端口不一致，出于安全考虑，跨域的资源之间是无法交互的 二、跨域的常用参数 1、“Access-Control-Allow-Origin”:"*" Access-Control-Allow-Origin是HTML5中定义的一种解决资源跨域的策略。 "*": 表示该资源谁都可以用* 2、“Access-Control-Allow-Methods”:"*" 意思...
详解可跨域的单点登录(SSO)实现方案【附.net代码】
10-21
SSO允许用户在多个服务和应用系统中只需进行一次登录验证，便可以获得对所有系统的访问权限。而可跨域的SSO解决方案则进一步解决了不同域名下的系统认证问题，使得用户跨域使用服务时也能实现统一的身份验证和授权。...
前端老赵一次给你讲透“微前端”架构
关注老赵不迷路，老赵带你上高速
03-08 839
微前端是一种前端架构模式，它将Web应用程序拆分为一组小型、可独立开发和部署的模块，每个模块可以由不同的团队开发和维护。这种模块化的架构可以帮助开发团队降低Web应用程序的规模和复杂度，从而提高应用程序的可维护性和可扩展性。微前端的概念最早由ThoughtWorks公司的技术总监Cam Jackson在2016年提出。他认为，微前端可以帮助团队将大型Web应用程序拆分为小型模块，从而更好地满足不同业务需求，提高应用程序的可维护性和可扩展性。
利用自我监督进行跨域人群计数
5341利用自我监督进行跨域人群计数刘伟哲1Nikita Durasov2 Pascal Fua21腾讯人工智能实验室2CVLab，EPFL摘要用于在拥挤场景中计数人数的最先进方法虽然有效，但这些数据驱动的方法依赖于大量的数据注释来实现良好的...
如何理解跨域？
weixin_52777510的博客
02-02 380
跨域是什么？ learn 【连载】the first time项目日志（一）——做项目查资料 =>转载自博客http://blog.itpub.net/31562041/viewspace-2564416/ 【连载】the first time项目日志（二）——做项目查资料 =>转载自博客https://blog.csdn.net/lambert310/article/details/51683775 跨域，指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器施加的安全
跨域的理解
weixin_69043473的博客
05-06 339
1,什么是跨？ a.跨域是指浏览器不能访问其他浏览器的脚本，它是由浏览器的同源(同一个域)策略造成的是浏览器对JavaScript实施的安全限制。 跨域形成：浏览器是从一个域名的网页去请求另一个域名的资源时出现的(域名，端口，协议）任意一个不同，都属于跨域。 b.非同源限制 1，无法读取非同源网页的 Cookie、LocalStorage 和 IndexedDB 2，无法接触非同源网页的 DOM 3，无法向非同源地址发送 AJAX 请求 2，如何解决跨域？ a,CORS 是跨域资源分享（C.
你真的了解跨域吗
qq_43430453的博客
07-13 779
前言相信每个前端对于跨域这两个字都不会陌生，在实际项目中应用也很多，但跨域方法的多种多样让人目不暇接，前段时间公司同事出现了跨域问题，又一时找不到问题所在，所以在此总结下跨域知识，一篇由...
简单理解一下什么是跨域
qq_45591403的博客
08-22 470
1. 什么是跨域？ 因为浏览器有同源策略，是判断一个浏览器是否合格的最基本的标准 什么是同源？ 是浏览器通过这个策略，将不同的网站分类(隔离)，就确保了信息的安全。你想一想要是没有这个东西，我们是不是可以随便请求淘宝接口，甚至给post一些信息到它们接口上，可能就乱套了 所以它是很必要的，我们再来明确一个概念，需要达到3个条件，相同协议，相同域名，相同端口，才能通讯。 项目 Value 是否允许通讯 http://www.A.com 和https://www.A 不同协议
谈谈对跨域的理解
前端小贤
02-10 1516
javacript处于安全方面的考虑，不允许跨域调用其他页面的对象，什么是跨域呢？简单的理解就是因为javascript同源策略的限制，a.com域名下的js无法操作b.com或者是c.a.com域名下的对象     处理跨域的方法一： 代理（后台技术）通过在同域名的web服务器端创建一个代理：背景服务器（域名：www.beijing.com）上海服务器（域名：www.shanghai.com）比...
跨域是什么呢?为何要跨域?你知道实现跨域的几种方式吗？
一亩地的专栏
01-15 1487
你知道实现跨域的几种方式吗？ 首先来提几个问题，大家看自己是否了解：               为什么会有跨域这个名词的出现呢?               跨域又是什么呢?为何要跨域?               浏览器的同源策略又是什么?怎么解决?               jsonp又是什么?               跨域的原理又是什么呢? 接下来为大家一一做下解释： ...
跨域是什么，如何解决跨域
守灯者的博客
12-29 1251
跨域问题其实就是浏览器的同源策略所导致的；当我们在访问缓存，页面通信，访问接口是容易出现跨域问题；这里介绍了JSONP、CORS、反向代理等方法来解决跨域问题。
跨域到底是什么
m0_46791709的博客
07-16 484
什么是跨域 简单来说跨域是指一个域下的文档或脚本想要去去请求另一个域下的资源 其实一些像A链接、重定向、表单提交的资源跳转，像 <link>、<script>、<img>、<frame> 等dom标签，还有样式中 background:url()、@font-face() 等嵌入的文件外链，又比如一些像 js 发起的ajax请求、dom 和 js 对象的跨域操作等等都是跨域，我们通常所说的跨域，大多是由浏览器同源策略限制引起的一类请求场景，这里你可能注意到了
跨域的精辟解释
一键写代码的博客
06-13 427
不要再问我跨域的问题了
什么是跨域?跨域的三要素
最新发布
09-07
跨域，全称同源策略(Same-Origin Policy)，是浏览器的一个安全特性，它限制了网页从当前源加载数据的能力，特别是对于像JavaScript这样的客户端脚本。简单来说，如果一个网页（被称为“源”）试图从另一个域名、协议...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值