经过1个多月的努力，AJBridge终于重生了，说起这个还得感谢玉伯同学的 KISSY 和他 诚挚的帮助。

说实话，“不当爹的不知道当爹的苦”这句话我可是深度体会了。

文档：

     AJBridge：http://kissyteam.github.com/kissy-ajbridge/

     KISSY.Flash： http://kissyteam.github.com/kissy/docs/index.html

历史：

2010年09月02日  AJBridge发布 。 ver. release 1.0

                                同时完成 AJBridge 和 Store 的 API文档  http://kissyteam.github.com/kissy-ajbridge/ 

2010年09月01日  AJBridge 预发布。ver: 1.0.12   。

                                同时发布 flash 本地存储库  Store。

2010年08月26日  AJBridge review。并依据最新的 KISSY库特性进行了重构。

                                 同日，Kissy-AJBridge库开始正式运作。

                                  至此 AJBridge 正式成为 KISSY的继 KISSY editor 子项目的另一项子品牌。

2010年08月25日  经陆陆续续的空余时间，终于将新人指引文档完成。  

2010年08月16日  开始撰写KISSY.Flash指引文档

2010年08月03日  KISSY  1.1版发布（已包含 KISSY.Flash）。

                                 同日，基于该版本的 KISSY.Flash 和 AJBridge 以及 SWFStore 重新撰写 并加入 标准测试页。

2010年08月02日  撰写完成 KISSY.Flash API文档。

2010年07月27日  完成可运行的KISSY.AJBridge

2010年07月26日  开始着手写KISSY.AJBridge

2010年07月25日  KISSY迁移至github安家。同时，确定了 AJBridge在 KISSY中所扮演的角色，见玉伯的《KISSY 迁移到 github.com》

2010年07月23日  完成可运行的KISSY.Flash

2010年07月21日   开始着手写KISSY.Flash 

2010年06月30日  尝试应用AJBridge的新白名单机制至SWFStore中。

                                 由于YUI的SWFStore还在beta阶段，并且有一些bug。

                                 考虑到后期维护以及和之前版本统一及合并的问题最终决定和KISSY的初衷一样，自己来创建。                       

2010年06月29日  增加了AJBridge的AS部分的白名单机制，借鉴了 YUI SWFStore的 白名单机制。

2010年03月18日  某些原因接触了 公司某WEB IM 的 flash相关部分业务。接触了YUI 的SWFStore.

                                 意外的发现代码部分如此相似，似乎印证了本人“一个弹坑可以落数个炮弹”的结论。

                                 同月参加“CM”项目，虽然竞标项目失败，但是从此接触了“KISSY”。

2010年01月04日  应用到公司的一个内部项目，代号“HYQ”

                                 期间发现并修复了一些代码

。。。                    孤独......莫非快死掉了么.........

2009年11月19日  增加了demo，并修改代码，支持多事件多swf。

2009年11月11日  修复一些bug，优化了代码 ver.r3。

2009年11月10日  修复一些bug。ver.r2。

2009年11月06日   第一版完整代码的 AJBridge 诞生,并上传至 google code 的 AJBridge项目。

                                  同时又撰写了一篇博文做记录

2009年11月05日    决定使用 google code 进行代码管理。

2009年10月28日    决定开始编写 AJBridge。目的仅仅是封装AS和JS通信的公用部分，减少工作量。

请访问 http://kissyteam.github.com/kissy/docs/flash/practice/index.html

 说之前先说下KISSY.Flash的任务目标：

• 支持多SWF管理。
• 支持动态、静态两种方式获取SWF。
• 对第三方参数 flashvars的值进行有向过滤（动态）。
• 支持第三方参数flashvars的内容，深度大于1。 
• 支持第三方参数flashvars深度大于1的内容JSON串化。
• 支持在线安装最新的flash播放器。
• 对不支持开发者期望版本的客户端提供具体的错误参考。

再说说这个库的构成。

• flash.js                              对KISSY抽象资源做了约定，便于未来的更改升级，并确立了 KISSY.Flash的命名空间。
• flash-embed.js               当前 KISSY.Flash 具体逻辑和功能的实现主体。
• flash-ua.js                        针对KISSY.UA的扩展，提供对客户flash播放器版本判断以及开发者期望运行版本检测。

此次主要说的是第一条关于SWF多条管理的抽象资源   flash.js。

看第一次代码：

KISSY.add('flash', function(S){

S.Flash = {

instances: { }, //存储每个已获取到的 swf 的 html元素

archives: []     //存储每个swf的id

};

});

当初这样的设计是为了能对 swf进行通过序列操作，并能获得附加SWF个数统计，以及快速的对象获取。

而且当初设定了 KISSY.Flash 就是个静态对象，因此对 swf个数的获取需要动态的。

而之后的从简单和容易记的角度上来考虑，于是觉得 用 swfs 代替 instances和 names 代替 archives 更好的从字面理解存在的意义和便于记忆。

KISSY.add('flash', function(S){

S.Flash = {

swfs: { },

names: 

};

});

后来，玉伯同学说既然获取/操作swf都需要id，且并以此作为swfs的key，不如就直接将names称为ids。

看上去是个好主意，于是又有了

KISSY.add('flash', function(S){

S.Flash = {

swfs: { },

ids:[]

};

});

心想，这应该完美了吧，但事实上世界本就无完美，如人无完人一样。

在实际操作过程中真正通过 index搜寻 swf的用途很少，而开发人员往往在一开始就可以预定id。

KISSY的原则就是2/8原则，只挑最好的，不挑最少的。

因此再三考虑决定废弃 ids这个数组对象。

但是问题来了，没有了数组，我们就无法动态获取SWF个数，而具体的实现要在后续的  flash-embed.js中实现。

于是根据抽象资源提供基本接口的约定，因此决定向swfs中加入length属性，通过 后续的增删操作提供增减操作。

而当时想到的是  swfs既然是个类 list 应该具备 length 属性，于是又有了以下代码：

KISSY.add('flash', function(S){

S.Flash = {

swfs: {length: 0 }

};

但是，总觉得这样写风险还是很大，比如某个 swf的 id 就叫 length。于是在存储规则中增加了一条规则：每个id都具有 “#”前缀。

这样就不会有污染，而且ID前带 “#”符合了 KISSY的DOM 选择器规则。这看起来很完美了。

可实际在做KISSY.Flash扩展的时候，问题又来了，由于swfHTML元素的id决定了as调用swf 唯一性，而这样的更改必然会对后续的操作带来一些工作。

比如正则处理ID。

但这样做又违背了 KISSY中的 一个S ------简单。

于是基于以下两点考虑最终让此静态抽象资源对象走向了最“幸福”的一站：

• swfs应该是个池，而且是应是个纯粹的“一一对应池”。
• 既然Flash就是个静态抽象资源对象，且管理多个实例，其本身也类似  collection ，更何况后续会有  add/remove/get，因此应该用最方便最易解的length。

于是。。。。事情就是那么简单。。。。。简单就是美嘛。。。。

KISSY.add('flash', function(S){

S.Flash = {

swfs: { },

length: 0

};

这样的好处可以直接通过  S.Flash.length获取到 Flash的个数。而之前则为了达成 获取 Flash中 SWF的个数采用了 length()或len()去获取S.Flash.swfs.length。

总结：

      事实上，我们在做开发的时候应该遵从第一直觉，既为了达成某项目标，其惯例或者说约定成俗的方式是什么。而理性往往不一定是对的，就好像对swf的个数统计就应该源于 swfs。但事实上作为使用者来说，更倾向于“我给谁了就向谁拿”的习惯，因此基于这2点 将 length作为属性直接写在静态抽象资源类上更适合不过了。

下一篇我将会隆重的介绍  KISSY.Flash 具体使用方式和过程。

KISSY Flash源码   ：http://github.com/kissyteam/kissy/tree/master/src/flash/

KISSY Flash文档  ： http://kissyteam.github.com/kissy/docs/flash/index.html 

猜想：相信即将出来的flash player 11或者之后版本，以及随之的sdk将支持webgl 同时按oGL4.0规格。

告别了 SVN，向git前进 ！

第一次版本库，管理 上 svn，那是3年前的 事情。。。。

由于某些私人原因，走向了hg，目的上满足脱机和分布式工作。

事实上，我还是比较喜欢hg的。

只是现在大部队 Kissy走向了git。

因此，未来为了更好过渡管理和使用版本库，因此也加入了git行列。

请祝我顺利吧~~~

哦，对了 ，注意置顶 kissy 地址哦。

从3.2.15 逐步升级到 5.0.0 真受痛苦，之后的版本由于本人愚钝。。。还是无法升级至最新的isroc。。。。

话说最新的编辑器让我非常郁闷。。。缺少了代码的所见即所得的部分。。。。

 感谢 “日月土成”“手气不错” 的贡献，kissy UI 上线。

地址：http://kissyui.com/

你会说：“纳尼~~  这不是 kiss  YUI 么？”

没错！咱们就是和YUI有着很渊源的关，但又不是它！

不过话说回来，大家都太忙了，建设站点还需要一些时间。

不过一定会有惊喜，请期待吧！

 http://www.infoq.com/cn/news/2010/05/Jarlsberg

很多人都想知道黑客是如何攻击并进入到系统的，为了帮助他们，Google创建了一个特殊的名为Jarlsberg 的实验室，其中的应用程序满是安全漏洞，开发者可以利用它以实践的方式学习到潜在的漏洞是什么样的，恶意用户是如何利用这些漏洞的，以及如何做才能免受攻 击。

这个实验室是围绕安全漏洞的不同类型来组织的，对于每个漏洞，都有找寻和攻击漏洞的任务可供完成。 该实验室使用了下列三种主要的技术：

• 黑盒：用户看不到应用程序的源代码，因此他们需要猜测服务器工作的方式，从而设法利用安全漏洞。
• 白盒：以开源应用的形式提供了源代码（Python）。 用户可以阅读代码，从而找到弱点所在。
• 灰盒：实验室会给出一些应用程序是如何编写的提示，但不会让用户看到完整的源代码。

Jarlsberg特意使用了大量特 性，以扩大应用程序的攻击面。

• 代码片段中的HTML： 用户可以在代码片段中包含特定的HTML代码。
• 文件上载： 用户可以向服务器上载文件，例如，在他们的代码片断中包含图片。
• Web形式的管理： 系统管理员可以使用web界面来管理系统。
• 新建账号： 用户可以创建属于自己的账号。
• 模板语言： Jarlsberg模板语言（JTL）是种新语言，它使得开发者可以更容易地编写网页，作为直接与数据库连接的模板。 你可以在jarlsberg/jtl.py找 到JTL的相关文档。
• AJAX: Jarlsberg使用AJAX来实现在主页和代码片断页中的刷新。 如果不需要特别关注AJAX内容，你可以忽略Jarlsberg中的AJAX部分。

在Jarlsberg中，你可以找到、利用并最终修复以下安全漏洞：

• 跨站点脚本攻击（XSS）
• 跨站点伪造请求攻击（XSRF）
• 跨站点包含脚本攻击（CSSI）
• 客户端状态操控攻击
• 路径模式发掘攻击
• 拒绝服务攻击（DoS）
• 执行代码攻击
• 配置漏洞
• AJAX漏洞攻击

你可以在本地运行该实验室，以在整个学习过程中完全掌控该实验室；或者也可以在Google的云中作为沙盒实例运行。 该实验室大部分是基于Creative Commons Attribution 3.0协议发布的，但也有一部分是基于Creative Commons Attribution-No Derivative Works 3.0协议发布的，这使得对于大学培训学生或者公司培训员工，让他们理解并 保护他们系统免受安全漏洞影响都是很理想的。

查看原文：Learning About Security Vulnerabilities by Hacking Google’s Jarlsberg