CommentCoreLibrary目前的过滤器共有三重，分别为“规则过滤器”，“函数预处理器”和“行进间修正器”。

第一重过滤器 规则过滤器

规则过滤器是一个基于简单语法规则的弹幕过滤器，设计宗旨是能让观看者简单定义过滤器规则又能发挥强大的智能过滤效果。与传统的正则表达式过滤器相区别的是，规则过滤器提供的可扩展性语法更加强悍匹配对象。

规则过滤器采用一套近似编程判断式的语法，但是规则及其简单：[对象.属性] [操作符] [内容]

对象是一个能简单表达过滤器过滤对象的特征字符，比如 $ 表示“滚动弹幕”，即弹幕类型 1,2 ，而 B表示底部弹幕，P表示定位弹幕等等。属性是弹幕对象的原始属性的内部表达，比如 text 是弹幕内容文字，color是弹幕颜色，size是弹幕大小等等。操作符是一种用于进行判断的符号，比如 == 表示相同于…时过滤， ~ 表示匹配正则表达式…则过滤，range 表示数字在某范围内则过滤等等。内容则是符合对象相应属性下的可被操作符操作的一个样本。

第二重过滤器 函数预处理器

函数预处理器，是在应用CCL时候通过页面写入的（或许也可动态载入），它是在JavaScript下定义的一个或一组函数，在弹幕被展示到荧幕之前，所有弹幕的原始数据都会经过预处理器。预处理器与过滤器不同之处在于，预处理器不但能阻挡弹幕，还可以通过改变弹幕的属性而对弹幕“预处理”后再放出。

比如下面的代码会让所有的弹幕变成白色，小号滚动弹幕：

cm.filter.addModifier(function(cmt){
    cmt.size = 16;
    cmt.color = '#ffffff';
    cmt.mode = 1;
    return cmt;
});

很酷吧，我们还能叠加一些弹幕的属性，呈现出更加奇特的效果。当然这都由你来发挥。

第三重过滤器 行进间修正器

行进间修正器是最后一重过滤设计，它是一个单一函数，用于处理弹幕生命过程中的一切重新定位效果。它在每条弹幕的每次运动触发器触发，并且可以最大限度的进行弹幕的行进间设定，有了这个修正器，我们可以实现非常奇葩的弹幕修正效果。

举下自带fefx库里面的两个例子：

可以看到，中间的滚动弹幕透明度很高，而两端的弹幕则相对清晰

弹幕中央隐藏： 有些人可能不是很适应弹幕播放器的文字在视频上方划过而阻挡下面的视频内容，当然，你可以通过设定透明度来解决一部分问题，不过这里有一个更好的方式——载入弹幕中央隐藏修正器。

弹幕中央隐藏行进间修补的实现模式如下：检测弹幕类型 mode == 1 || mode == 2 ，计算一下位置 pos = ttl/dur（生存剩余时间/生命周期），计算透明度（pos > 30% && pos < 70% : opacity = 0.2 else : opacity = 超出的比例 * 0.8 + 0.2）。

弹幕飘过中部的时候加速通过

弹幕中央加速：同样也是为了降低弹幕的阻挡时间，弹幕中央加速用于在弹幕移动到中部位置的时候，加快其行进速度，从而降低阻挡画面的时间。和前面的实现相似，本过滤器采用缩短弹幕生命剩余时长的方式让弹幕快速通过。

其他

当然，除了这些改进之外，CCL还增加了一些稳定性和兼容性的改进，比如在Chrome和Firefox下可以统一弹幕中的“换行” 等。有兴趣可以继续关注  https://github.com/jabbany/CommentCoreLibrary或者 到： http://tools.kanoha.org/experimental/CommentCore 进行体验！

IOCCC大赛（世界C语言混乱化大赛）的宗旨是让程序员写出最“难懂”，“诡异”或是让人捉摸不透的艺术性代码。单程序被限定在4KB以内，要以视觉上或理解上最坑的方式作出有功能的代码。

之前坑了几年，今年打开了获奖名单，发现第一位是一个叫做Akari的投稿，作者是Don Hsi-Yun Yang，然后看着这名字和作品名字，貌似有印象之前见过这位的另一个获奖神作，把校验码放到文件本身的。

好奇之下代开了源码和说明，然后，请见上图。当然，IOCCC的要求是，除了“艺术性（所谓‘混乱’的代码排版）”以外，程序还要有足够靠谱的功能性。这个程序获得了最佳展示奖——最能“收缩”。

程序的本体是一个图片压缩器，可以将 Pixmap和ASCII字符画的图片进行向下压缩大小（缩放），当然了，这仅仅是第一层。你会发现，程序本身就是一幅ASCII字符画，而把程序的源码通过编译版的程序之后，则会获得另一个缩小了的源码。令人吃惊的是，这个缩小了的源码，依然是有效可编译的。编译后又是一个文字过滤器，可以对文字进行rot13“加密”。当然作者说，这并不是终极，再把缩小后的ASCII程序再缩小一次，将获得第三个程序源码，继续缩小则会获得第四个程序源码。后两个程序源码编译运行后，会分别在屏幕上输出文字。

当然，这个颇有存在感的二次元向作品以外，还有很多神奇的优秀作品。比如：世界上最“无需说明文档”的科学计算器。

会让你吃惊它居然是拿C语言完成的，而且完全不会出现编译警告。

投稿作品从游戏到算法，从“绘图”到“计算”，涵盖了各种领域。而代码的样式更是多种多样（单行程序、反语法程序等）。如果你觉得你的C语言程度足够好，快去看看这些奇葩的程序吧。

一般来说现在网络上的诸多漏洞都是采用升权（借用用户权限）进行的攻击。最常见的就是插入脚本的XSS攻击。由于脚本运行在用户相同的安全性标准下，这种漏洞经常会引发负面的越权问题。同理，CSRF漏洞多数也是采用升权进行的攻击，于是不断被忽视的就是CSRF降权拒绝服务攻击（名字是原创的，你未必找得到）。

一、什么是CSRF漏洞

CSRF是Cross Site Request Forgery（跨站点请求伪造）的缩写。这种攻击不同于XSS脚本注入攻击的最大区别是，攻击利用了浏览器对资源的载入来诱导浏览器发出能改变状态的请求。我们举一个例子：

某一个虚拟社区对用户进行积分转账是靠如下的访问：http://foo.com/bar/?action=transfer&to=205&amount=33

其中在请求的GET参数中，to是积分转账的授予用户，而amount则是转账的数目。在已经登录的系统下，程序将会授权用户的这次操作。而作为攻击者，由于无法在对方帐号的权限下访问网址，理论上也是无法进行转账的。

但是事实并非那么简单。浏览器在访问网页时，会自主下载一些资源，比如：图片、音乐、样式表、脚本文件。这些文件的下载（准确些说，是这些请求的发出）经常并没有用户独特的许可，但是却带着用户的权限进行。很显然，我们不能询问用户每一个资源的下载是否许可，但是大部分情况下，浏览器也不会胡乱请求资源。CSRF攻击正是利用了站点对用户浏览器的这种信任而得以实现的。

假定刚才的社区里，有一位用户引用了一张图片：<img src="http://foo.com/bar/?action=transfer&to=205&amount=100" />

浏览器在载入页面的同时，也将发出请求载入这张图片作为辅助资源。就这样，浏览器作为中间人代替了用户发出了这个请求，也就实现了浏览器的“升权”（自行代表了用户的权限）。凡是访问到包含这个图片的页面，已登录用户的浏览器将会带着一套已经认证的权限来执行操作。于是便在用户未主动参与的情况下发出了一个并不应该发出的请求，也就会导致100个积分被转到UID=205的账户。

二、CSRF的杜绝和被忽视的降权拒绝服务

虽然说刚才那一段听起来很危险，但是实际上不会出现这样的漏洞了，因为大部分的应用已经考虑到了并阻断了CSRF的功效发挥。其实阻断CSRF非常简单。CSRF的成功发动需要两个条件：1）你能诱导浏览器发出此类请求 2）请求不能因人而异。

这样一说，就发现有两个非常简单的解决方法。对于第一条，可以通过把请求由GET变为POST进行解决（浏览器不会自主发出POST请求的）。而对于第二条，很多站点则采用了NONCE（一次性校验数字）来进行的防御。此方法是，在生成连接时加入一个传递NONCE的字段。生成一个数字，保存在服务器上，同时也加到链接里面。当访问链接时，程序对比两个校验数字是否一致，然后再进行下一步操作。URL由 http://foo.com/bar/?action=transfer&amount=100&to=205 变为了http://foo.com/bar/?action=transfer&amount=100&to=205&nonce=29374920 而这个数字也会被保存到服务器。下次生成链接，数字则会发生变化。这时由于无法找到固定的可用的链接，CSRF也就失效了。

这种防御虽说解决了很多问题，但是在很多地方也有着许多劣势。比如GET转POST会导致用户无法使用“返回”操作，也会导致用户必须亲自点击发出请求。这在一些反复使用的地方就会显著增加复杂度。而NONCE则会花服务器的处理开销和内部存储，甚至过期时还需定时清理。有时检查链接请求的REFERER头部信息也能有效的过滤CSRF，但是对于没有REFERER的请求，是抛弃（会导致大批量的用户无法使用）还是默许（于是就没作用了），也成为了困难的选择。

或许想着这些开销，很多站点、网络应用就在一个地方进行了简化：登出链接。不同于上面的操作，登出链接是用户主动放弃高权限（登录状态），进入低权限状态（未登陆），所以在登出环节内不设防范并不会造成用户出现不必要的损失。于是我们能见到各种形如 http://abc.com/logout 的单向“干净”链接，而这些无害的链接则也同时没有任何保护。

说到这里就要讲讲基于CSRF的降权拒绝服务攻击。由于现在很多服务都会载入信息流（即别人的信息和自己的进行流整合）而且很多时候，外链一些图片是不可避免的，所以则会发生降权拒绝服务攻击。攻击通过刻意分享登出链接，让加载信息流的用户“被迫”放弃了登陆状态，而终止了后面的需要认证的步骤。一旦重新登陆，再次载入了恶意信息流，再次被动发出登出请求，再次被登出。如此反复，虽然并没有开放任何的安全隐患，但是短时间内大量的导致用户被迫登出而实现了拒绝服务攻击。

<img src="https://accounts.google.com/Logout?hl=en&continue=https://www.google.com/" />

三、这个到底和WEB APP有什么关系？

现在越来越多的网络应用正在冲入日常生活，然而这种不经意间的登出，或许会在短时间内造成困扰。由于降低权限并不构成很大的安全问题，所以CSRF的降权空间很大。大到Google的账号，小到人人网，一张图片足以瞬间登出。

看一看解释，是不是明白了这个似乎是BUG但是又不那么BUG的“漏洞”呢？

• 重新写了HTML文档解析器，增强了JS文件解析。现在解析JavaScript脚本的机制更加柔和，避免因为代理误把 JS 脚本内的一些字符串破坏导致的全脚本失效现象。如果幸运的话，也许还会对 AJAX成功率有增强。
• 修正了引入WebSockets之后在该模式下的URL BUG。该模式仅在无cURL时才启用。
• 升级了加密组件的基钥匙，如果希望保留旧地址，请不要覆盖module_encoder.php

由于Sourceforge连续抽风，没法设置默认下载，所以更新将在 https://github.com/jabbany/knProxy 获得，同时也可以到 SourceForge上下载压缩后的程序包。

CommentCoreLibrary是ABPlayerHTML5的弹幕核心元件，也是任何有希望了解弹幕播放器原理或是自己实现弹幕播放器的开发者们可以参考的一个JavaScript库。各种功能，如空间拆分器、弹幕过滤器等都被分开存放，让主文件更加易懂。而且稍微改变了几处的实现、修复了几个有关3D弹幕，3D运动弹幕的BUG之类的。目前可以比较正确的解析大部分的神弹幕，当然文字拼图的弹幕由于WEB字体过大所以依然有些问题。

运行性能测试：http://tools.kanoha.org/experimental/CommentCore

相比之下ABPlayerHTML5的下一步是完善播放器的操控界面，如：播放进度条，弹幕列表，发送器等。

还有，ABPlayerHTML5 改进了获取Sina片源的机制（从猜地址法换到利用接口），主要感谢B站的Android客户端里面提供的Sina地址接口。

现在获取Sina的HTML5对应视频VID可以通过：
http://video.sina.com.cn/interface/video_ids/video_ids.php?v=vid返回的JSON对象获取。获得的地址可用在：
http://v.iask.com/v_play_ipad.php?vid=ipad_vid来直接进行外链播放！

比较好的是，这样漏掉的可能性大大的降低了。但是比较不好的是，搜索框输入很多内容时可能稍微浪费处理资源，特别是在静态版的Google 搜索结果。这一点还是忍一忍吧。

新版本的插件还引入了自动更新功能，以后会随着Google的变化自动更新。不过为此需要删除原插件，并更换最新版本插件。请注意，这次更新完本插件后，未来将可以利用插件本身的自动更新机制，不必再行下载。

下载最新版本：SkipGoogle.crx （下载次数：210）