跨域脚本

Ⅰ 在Jenkins中报严重违规：Servlet反射跨域脚本漏洞 writer.print(value);

脚本（script）是使用一种特定的描述性语言，依据一定的格式编写的可执行文件，又称作宏或批处理文件。脚本是批处理文件的延伸，是一种纯文本保存的程序，一般来说的计算机脚本程序是确定的一系列控制计算机进行运算操作动作的组合，在其中可以实现一定的逻辑分支等。

Ⅱ 为什么要跨域以及跨域的作用是什么

跨域，指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器对javaScript施加的安全限制。

Ⅲ 跨域有哪几种方式

跨源资源共享

通过 XHR 实现 Ajax 通信的一个主要限制,来源于跨域安全策略。默认情况下,XHR 对象只能访 问与包含它的页面位于同一个域中的资源。这种安全策略可以预防某些恶意行为。但是,实现合理的跨 域请求对开发某些浏览器应用程序也是至关重要的。

CORS(Cross-Origin Resource Sharing,跨源资源共享)是 W3C 的一个工作草案,定义了在必须访 问跨源资源时,浏览器与服务器应该如何沟通。CORS 背后的基本思想,就是使用自定义的 HTTP 头部 让浏览器与服务器进行沟通,从而决定请求或响应是应该成功,还是应该失败。

比如一个简单的使用 GET 或 POST 发送的请求,它没有自定义的头部,而主体内容是 text/plain。在 发送该请求时,需要给它附加一个额外的 Origin 头部,其中包含请求页面的源信息(协议、域名和端 口),以便服务器根据这个头部信息来决定是否给予响应。下面是 Origin 头部的一个示例:

这个例子通过查询地理定位服务来显示你的 IP 地址和位置信息。
JSONP 之所以在开发人员中极为流行,主要原因是它非常简单易用。与图像 Ping 相比,它的优点 在于能够直接访问响应文本,支持在浏览器与服务器之间双向通信。不过,JSONP 也有两点不足。

• 首先,JSONP 是从其他域中加载代码执行。如果其他域不安全,很可能会在响应中夹带一些恶意代码,而此时除了完全放弃 JSONP 调用之外,没有办法追究。因此在使用不是你自己运维的 Web 服务时, 一定得保证它安全可靠。

  
  

• 其次,要确定 JSONP 请求是否失败并不容易。虽然 HTML5 给<script>元素新增了一个 onerror 事件处理程序,但目前还没有得到任何浏览器支持。为此,开发人员不得不使用计时器检测指定时间内是否接收到了响应。但就算这样也不能尽如人意,毕竟不是每个用户上网的速度和带宽都一样。

  
  

参考：javascript高级程序设计第21章

Ⅳ 什么是跨域

跨域就是跨，领域区域，个人是这么认为，主要看那方面

Ⅳ 如何解决跨域问题

关于跨域名问题还是问题么，这方面的解决实践非常多，今天我就旧话重提把我所知道的通过几个应用场景来分别总结一下（转帖请注明出处：http://blog.csdn.net/lenel）

先说明一点：我说的某某域名在您的控制下的意思是这个域名下的网页由您来负责开发内部的JavaScript
场景一：将bbs.xxx.com的页面用iframe嵌入到www.xxx.com的中，如何在iframe内外使用js通信（转帖请注明出处：http://blog.csdn.net/lenel）
一级域名都是xxx.com 这个域名一定是在您的控制下，所以你只要在两个页面中同时升级域名即可
在父窗口和iframe内部分别加上js语句：document.domain="xxx.com";
之后2个页面就等于在同一域名下，通过window.parent oIframe.contentDocument就可以相互访问，进行无障碍的JS通信
在新浪、淘宝等很多页面都能找到这样的语句。不过document.domain不可以随便指定，只能向上升级，从bbs.xxx.com升级到yyy.com肯定会出错

场景二：将www.yyy.com的页面用iframe嵌入到www.xxx.com的中，两个域名都在您的控制下，如何在iframe内外进行一定的数据交流（转帖请注明出处：http://blog.csdn.net/lenel）
你可以通过相互改变hash值的方式来进行一些数据的通信

这里的实现基于如下技术要点：
1、父窗口通过改变子窗口的src中的hash值把一部分信息传入，如果src只有hash部分改变，那么子窗口是不会重新载入的。
2、
子窗口可以重写父窗口的location.href，但是注意这里子窗口无法读取而只能重写location.href所以要求前提是您控制两个域名，知
道当前父窗口的location.href是什么并写在子窗口内，这样通过parent.location.href =
"已知的父窗口的href"+"#"+hash。这样父窗口只有hash改变也不会重载。
3、上面两步分别做到了两个窗口之间的无刷新数据通知，
那么下面的来说如何感知数据变化。标准中没有相关规定，所以当前的任意浏览器遇到location.hash变化都不会触发任何javaScript事
件，也就是说您要自己写监听函数来监视loaction.hash的值的变化。做法是通过setTimeout或者setInterval来写一个监听函
数每20-100ms查看一下hash是否变化，如果变化了驱动js根据新的数据做想做的事情。

这种实现的一些分析：
1、信息通道是双向的，当然会兼容单向，如果只是父窗口向子窗口通知数据，只需要子窗口写hash监听，反之亦然。
2、局限性也是颇大，因为这种通信的前提是双方知道对方的location.href。如果父窗口带有动态的location.search也就是查询参数，那么子窗口的处理上就比较困难，需要把父窗口的location.search作为传递信息的一部分告知子窗口。
3、另外的困扰会有浏览器带给你，IE之外的浏览器遇到hash的改变会记录历史，这样你在处理前进后退的时候会非常头疼

场景三：将www.yyy.com的页面用iframe嵌入到www.xxx.com的中，只有被嵌入的yyy.com在您的控制下，如何在iframe内外进行一定的交流
真实场景：google adsence的一个需求，你希望google发现您的页面不能匹配出相关性非常好的按点击付费广告时，你希望google的广告iframe能够隐藏。
google的广告iframe在google域下显然不能把自己隐藏掉，那么怎么办呢？
1、google会提供给你一个html页面
2、您将这个页面放置在您的域名下，并告诉google它的位置
3、当google发现没有很好的广告时，会将子窗口的loaction重定向到您的那个页面下，这样您的页面因为同域名就可以访问父页面来隐藏自己了
是不是很巧的方法？

场景四：您是内容发布商，如何改造接口，让其他域名下的页面可以从浏览器端出发获得您的数据
我们知道ajax的xmlHttpRequest()说到底是一个无刷新请求服务器数据的辅助工具，但是xmlHttpRequest并不能跨域名请求数据，在某些情况下成了极大的限制。
但是我们如果通过其他方式完成无刷新请求数据不也可以么，我们用Dom方法操作动态JS脚本请求来做这件事。
//创建一个脚本节点
var oScript = document.createElement('script');
//指定脚本src src可以指向任意域名
//注意src不再指向静态js，而是带着查询参数指向一个动态脚本广播服务。
oScript.src = "http://yyy.com/query.php?"+yourQueryString;

//如果指定了charset 同时还可以解决xmlHttpRequest另一大困扰 乱码问题

//oScript.charset = "utf-8";
//通过Dom操作把这个新的节点加入到文档当中
document.getElementsByTagName("head")[0].appendChild(oScript);

这样只要query.php的输出是可执行的javaScript脚本，比如：djsCallBack（{jsondata}）;
当他从服务器返回后就会自动执行,你可以方便的用json方式来做数据传递了。
要注意，您的脚本请求最好带上时间戳，避免浏览器缓存造成取回数据实时性下降。

如果您是数据提供者，您可以要求数据索取者在查询参数中提供回调函数名，比如query.php?callback=myDataHandler&key=...?
这样您就可以根据参数来提供给他myDataHandler({jsondata}),这样不同的数据索取者都会得到自定义的正确的异步回调。

进一步发展，可以做一个统一的从xml到动态json的数据转化服务器，脱离数据的实际意义，针对任何xml接口都可以作为转化后提供给客户端直接访问。
这样就不用针对单独xml数据服务，为了跨域名而做各自的后台数据抓取转化服务。

用动态脚本传数据功能非常强大，去年我最先在YAHOO的站点上看到这样的应用，让人眼前一亮。

总结总结：
第一种场景，相应的处理办法有这非常好的效果，可以说完全解决了问题。
第二种场景，相应的处理办法具有一定的跨域数据交流功效，具有相当大的局限，并不适合在复杂业务流程中应用，实际上我也确实也没看到过基于此的大规模应用。
第三种场景，相应的处理办法比较巧妙，虽然redirect之后就不干你什么事了，但如果你是google一样面向众多域名的内容提供商，也是个不错的解决思路。
第四种场景，相应的处理办法非常强大，对比Ajax可以看到，跨域名没问题，无刷新没问题，本身又是异步的，JSON比xml快的多，同时解决乱码问题，只是请求都是Get方式的，不能做Post方式的请求。多一种武器自然可以从容选择了

Ⅵ HTML5 script 标签的 crossorigin 属性到底有什么用

最近 Bootstrap 4 已经正式发布了，可能已经有爱尝鲜的小伙伴在 alpha 阶段就尝试过 BS4。不过今天要说的不是 BS4，而是官网里引入 BS4 框架依赖的 jQuery 的代码：

XHTML
1
2
3
<script src="https://code.jquery.com/jquery-3.2.1.slim.min.js"
integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN"
crossorigin="anonymous"></script>

看起来比以前的写法复杂好多的样子。先不着急慢慢看，多了一个 integrity 属性，看值的样子就知道是用来验证文件完整性的。另外还有一个 crossorigin 属性……怎么？直接通过 script 标签加载网站外 JS 资源也要开始考虑跨域的问题了吗？

这里不讨论 script 里 crossorigin 属性怎么用，以及服务器端如何支持此属性，MDN 上的文档已经说得很清楚。

不知道大家对此新属性的感觉如何，我的第一感觉是：新加了这么一个属性，难道是以前 script 不用 crossorigin 属性的时候，会出什么问题吗？到底可能会出什么问题呢？

从谷歌的结果来看，比较一致的说法是，引入跨域的脚本（比如用了 apis.google.com 上的库文件），如果这个脚本有错误，因为浏览器的限制（根本原因是协议的规定），是拿不到错误信息的。当本地尝试使用 window.onerror 去记录脚本的错误时，跨域脚本的错误只会返回 Script error。

script error

但 HTML5 新的规定，是可以允许本地获取到跨域脚本的错误信息，但有两个条件：一是跨域脚本的服务器必须通过 Access-Controll-Allow-Origin 头信息允许当前域名可以获取错误信息，二是当前域名的 script 标签也必须指明 src 属性指定的

Ⅶ 如何实现跨域

1.什么是跨域
经常会在页面上使用ajax请求访问其他服务器的数据,此时,客户端会出现跨域问题.
跨域问题是由于javascript语言安全限制中的同源策略造成的.
简单来说,同源策略是指一段脚本只能读取来自同一来源的窗口和文档的属性,这里的同一来源指的是主机名、协议和端口号的组合.