iframe

经常会遇到这样一种情况。 在iframe里嵌入另外一个页面时。如果iframe载入的页面响应较快，或许我们感觉不到页面载入的不同步，但试想，如果一个需要内嵌到iframe里的页面的响应很慢，这里会出现一种什么现象呢？这时将会出现所有页面已经载入完成，但在iframe元素处，将会出现空白，直到内嵌页面完成载入时，该空白处才会显示新载入的页面。 可想而知，一个页面如果长时间的空白，对于浏览者来说将意味着什么。 如果在内嵌页面未载入完成时，给出一种加载提示信息。如：“页面加载中”之类的，我想这对浏览页面用户来讲，将不再是煎熬，更是一种视觉上的享受。 为了实现这样的效果，一般会采用如下原理处理。 ·iframe载入区域给出友好的提示信息。 ·当iframe载入完成时，清空提示信息，而让iframe显示。 这些都比较容易，但现在的问题的关键是怎么监听iframe元素内的页面已经载入完成。 关键这个问题，一般来讲，会分两种情况的来讨论解决方案。 ·同域的嵌套。最好是让子页面调用父页面的方法。 ·如果是异域，但子页面无法修改，那么：在Firefox/Opera/Safari中，可以直接使用iframe onload事件；而在IE中，可以通过定时器测定子页面的document.readyState，或者使用iframe onreadystatechange事件计算该事件的响应。 1.同域嵌套。

经常会遇到这样一种情况。 在iframe里嵌入另外一个页面时。如果iframe载入的页面响应较快，或许我们感觉不到页面载入的不同步，但试想，如果一个需要内嵌到iframe里的页面的响应很慢，这里会出现一种什么现象呢？这时将会出现所有页面已经载入完成，但在iframe元素处，将会出现空白，直到内嵌页面完成载入时，该空白处才会显示新载入的页面。 可想而知，一个页面如果长时间的空白，对于浏览者来说将意味着什么。 如果在内嵌页面未载入完成时，给出一种加载提示信息。如：“页面加载中”之类的，我想这对浏览页面用户来讲，将不再是煎熬，更是一种视觉上的享受。 为了实现这样的效果，一般会采用如下原理处理。 ·iframe载入区域给出友好的提示信息。 ·当iframe载入完成时，清空提示信息，而让iframe显示。 这些都比较容易，但现在的问题的关键是怎么监听iframe元素内的页面已经载入完成。 关键这个问题，一般来讲，会分两种情况的来讨论解决方案。 ·同域的嵌套。最好是让子页面调用父页面的方法。 ·如果是异域，但子页面无法修改，那么：在Firefox/Opera/Safari中，可以直接使用iframe onload事件；而在IE中，可以通过定时器测定子页面的document.readyState，或者使用iframe onreadystatechange事件计算该事件的响应。 1.同域嵌套。

前端常见跨域解决方案（全） 什么是跨域？ 跨域是指一个域下的文档或脚本试图去请求另一个域下的资源，这里跨域是广义的。 广义的跨域： 1.) 资源跳转： A链接、重定向、表单提交 2.) 资源嵌入：<link>、<script>、<img>、<frame>等dom标签，还有样式中background:url()、@font-face()等文件外链 3.) 脚本请求： js发起的ajax请求、dom和js对象的跨域操作等 其实我们通常所说的跨域是狭义的，是由浏览器同源策略限制的一类请求场景。 什么是同源策略？ 同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指”协议+域名+端口”三者相同，即便两个不同的域名指向同一个ip地址，也非同源。 同源策略限制以下几种行为： 1.) Cookie、LocalStorage 和 IndexDB 无法读取 2.) DOM 和 Js对象无法获得 3.) AJAX 请求不能发送 常见跨域场景 URL 说明 是否允许通信 http : //www.domain.com/a.js http : //www.domain.com/b.js 同一域名，不同文件或路径 允许 http : /

在我现在正做在某个查询页面需求是：当使用键盘快捷键时，能自动触发例如查询，保存等操作。 由于我这里用到了masterpage和iframe，iframe随页面经常发生变化，所以键盘消息应该放到统一的处理方法，不能放到每个子页面。 利用事件流的冒泡机制，我们只需要捕获并处理document的onkeydown事件就可以了。 function document.onkeydown() { eventhandle(parm); event .keyCode = 0 ; event .returnValue = false ; } 为了能支持IE之外的其它浏览器，可以利用javascript高级编程中的EventUtil类库 window.onload = function () { EventUtil.addEventHandler(document, " keydown " , handle); } EventUtil类的addEventHandler方法提供了对IE和其它浏览器注册事件的支持 EventUtil.addEventHandler = function (oTarget, sEventType, fnHandler) { if (oTarget.addEventListener) { oTarget.addEventListener(sEventType,

网易云音乐貌似没有提供批量操作的功能，而这个歌单好像又不能删掉，所以删的时候得一个个删，相当蛋疼。不过看了下删除操作，是请求一个api，传递相应参数即可。 首先打开歌单页面，地址是： http://music.163.com/#/my/m/music/playlist?id=xxxxx 其中xxxxx是歌单的ID号，打开console，随便删一首歌，可以看到网络请求为： /api/playlist/manipulate/tracks?csrf_token=64f353b064b83d3c692ca05d4db2848a 请求参数： pid: xxxxx trackIds: ["yyyyy"] op: del 其中 csrf_token是请求api的令牌，有可能会失效，如果失效以后，刷新下页面，再删一首可以看到新的令牌 参数中xxxxx是歌单ID，yyyyy是要删除的歌曲ID ok，下面就来批量操作 打开console 加载jQuery(网易云音乐页面上没有使用jQuery) var jq = document.createElement('script'); jq.src = "http://libs.baidu.com/jquery/1.7.2/jquery.min.js"; document.getElementsByTagName('head')[0].appendChild

1，reload 方法，该方法强迫浏览器刷新当前页面。 　　语法：location.reload([bForceGet]) 　　参数： bForceGet， 可选参数， 默认为 false，从客户端缓存里取当前页。true, 则以 GET 方式，从服务端取最新的页面, 相当于客户端点击 F5("刷新") 代码如下 <script language="JavaScript"> window.location.reload(); </script> 　　这样就实现了页面刷新了，当然还有其它办法了，那么要刷新框架页面我们要如何操作 代码如下 //方法1 document.getElementById('FrameID').contentWindow.location.reload(true); //方法2 document.getElementById('your iframe ').src=src; 　　实例： 代码如下 <iframe id="myframe" width="100%" frameBorder="0" src="test.html" scrol ling ="no"></iframe> <input type="button" onclick=" javascript :refreshFrame();" value="Refresh Frame" /> <script

CSRF即Cross Site Request Forgery（跨站点请求伪造）。 用户在客户端（浏览器）上任何一个操作如提交表单、点击超链接、或者是页面资源的显示都是向服务器发起请求 而得以实现的，所以攻击者往往都是可以通过模拟真实用户的请求来“代替”用户完成操作的。 例如A用户删除id为18的文章的请求地址为：www.eco.com/delete?id=18 那么攻击者可以构造一个html页面，页面中有这样一段代码： *** <img src="http://www.eco.com/delete?id=18" /> *** （当然，用户会看到一张无法显示的图片） 然后引导A用户去访问攻击者的这个html页面，A用户看到了这样一张无法显示的图片，然后回到自己的博客，一看， 自己的id为18的文章不翼而飞了，这，就是跨站点请求伪造。当然了，CSRF肯定不会这么轻易就能成功的，因为大多 数web项目都会对http请求设置一个过滤器，用来验证发出请求的用户身份，使得CSRF的实施变得麻烦起来。 1.浏览器的cookie策略 我应该不止一次地说过，用户注册之后，会设置一个cookie（token）返回给客户端（浏览器），用于之后请求的身份 验证。 浏览器所持有的cookie分为两种，一种是“Session Cookie”、一种是“Third-party Cookie