有关Web技术和Ajax安全的资料分享

　　首先是今年在加拿大举行的第16届The International World Wide Web Conference，大部分papers都可以下载到PDF全文。比较值得一看的有：

• Subspace: Secure Cross-Domain Communication for Web Mashups
• The Complex Dynamics of Collaborative Tagging
• The Two Cultures: Mashing Up Web 2.0 and the Semantic Web

　　该大会明年在北京举行，也可以浏览历次的会议论文：http://www2006.org……

　　另外，与跨域访问和安全验证相关的还有来自Google的“New GData JavaScript library enables full read and write access for your mashups”，据说已经和AuthSub集成好，可以支持用纯JavaScript来完成数据写回的操作，而不再需要额外的服务器端代理包装了：

function logMeIn() {
scope = "http://www.google.com/calendar/feeds";
 var token = google.accounts.user.login(scope);
}

function setupMyService() {
var myService =
new google.gdata.calendar.CalendarService('exampleCo-exampleApp-1');
logMeIn();
return myService;
}

　　最后，关于Ajax的安全问题，记了这句话：“Ajax is not inherently insecure, but ignoring security makes it so”。

by William Cui 崔伟毅

Google发布Ajax API使得RSS混搭应用更容易

　　上周，Google的Ajax API团队新发布了一套实用的Ajax Feed API，使得基于JavaScript的RSS/Atom混搭应用比以往更加容易和直接。
　　和Google的其他众多API服务一样，应用开发者需要为某一网站申请域名一一绑定的API密钥。之后，便可以参照官方的JavaScript样本示例进行快速RSS混搭开发了。
　　可能对更多的Ajax开发者来说，Google的这一服务为他们雪中送炭地解决了一个JavaScript跨域访问“沙盒”安全限制的问题。通常我们如果需要跨域访问文档资料，不得不在服务器端增加一个代理层，通过相对复杂的服务器端程序巧妙地绕开该限制，这样的开发复杂度无疑抬高了RSS混搭应用的门槛，阻碍了普及化发展。
　　然而，由于通过Google Ajax Feed API获取的数据实际上只是Google服务器上的一个缓存（很可能和Google Reader等Feed聚合阅读器使用的是同一份缓存），而并非是最新的、精确的数据，这个多出来的一层在某些有特殊需求的场合下可能会受到一定的制约。
　　当然，将分散各地的Feed资源进行集中整合、过滤、缓存和再造的这一实践和思路，应该并不是Google首创的，著名的FeedBurner就是此类应用的一个较早的、也是较出色的例子，就是不清楚同样是整合了这么多Feed资源，FeedBurner为什么迟迟没有提供出Ajax Feed API之类的服务呢？或者说，大家还不是很清楚有这项服务。
　　另外，据说Microsoft也在上周将其Live Spaces的Feed服务全面扩充、升级，来迎合这一领域不断增长的用户需求。实话说，曾经对Microsoft大气宣传的在Outlook 2007和IE7中对RSS的直接支持一度看好，可惜用了之后才发现实在比较失望。让我们拭目以待，看看Microsoft又如何能够再度力挽狂澜吧！
　　更多的开发相关资料，请参考这篇开发者文档。

William Cui 崔伟毅

Morfik的"Ajax生成器"专利申请和GWT、Web Dynpro

　　近日，澳大利亚的Morfik科技公司向USPTO（美国专利商标局）提交了一个关于“Ajax生成器”的专利申请。该专利申请的名字为“System and method for synthesizing object-oriented high-level code into browser-side JavaScript，相关申请文献已经可以在USPTO网站上查阅，其摘要如下：

A system and method are provided to enable developers of web sites and software applications to code in an object-oriented high-level language that is compiled into a browser-side JavaScript which can be natively interpreted by a browser. This enables developers to program in a high-level language of choice to create browser-side web applications, instead of directly using the target lower-level language JavaScript.

　　进一步阅读，发现这个可能的“发明”是想为B/S开发人员提供了一套系统化的方法来达到以下目的，即把用高层OO语言（类Basic和Pascal，或者类Java和C#语法的）写的代码转化成可以被不同浏览器进行原生解释的JavaScript低层语言，从而简化了直接编写浏览器端JavaScript的复杂性，并在一定程度上降低了Ajax的开发代价。
　　说起“Ajax生成器”，我们可能第一个就会把它和Google的GWT（Google Web Toolkit）开源项目联系起来。GWT是一个开源的Java软件开发框架，用于开发类似于Google Maps和Gmail的Ajax应用程序。开发者可以用Java编程语言开发前台界面，然后用GWT编译器将Java类转换成适合各种浏览器执行的JavaScript与HTML。还有一个基于Eclipse开发插件Googlipse提供了GWT的集成开发环境。尚且还不知道Morfik的这一专利申请会不会和Google的知识产权存在法律上的问题了。就软件专利这一方面话题，我不久前写过一篇Weblog——漫谈“软件专利保护”。
　　此外，尽管SAP的Web Dynpro开发出来的不是严格意义上的Ajax应用程序，而且非SAP的客户或合作伙伴可能对Web Dynpro还不太熟悉，但是就我的实践和横向比较而言，在专业化的基于B/S的企业应用前台开发来说，Web Dynpro无疑大大走在了GWT还其他流行的Web MVC框架前面！这在SAP的Help Portal上有Web Dynpro的架构和开发模型方面的资料可以供研究参考。我也会在以后写一些文章来和大家分享SAP在这些方面的开发方法和实践经验。

William Cui 崔伟毅

Offline支持——Web的下一个热点！

　　回顾近十年的Web技术和应用，和历史上其他很多事物一样，多是有一些有趣的潜在发展规律的，值得整理如下：

• 随着上世纪末Web浏览器（以Netscape Navigator和Microsoft IE的浏览器大战为代表）的普及，基于B/S架构的Web应用开始流行起来，对传统的基于C/S架构的胖客户端应用带来了冲击。由于起初的一系列Web标准（HTML, CSS, JavaScript等）只是为瘦客户端所设计的，为了满足不断增长的Web应用需求，各大浏览器阵营陆陆续续增加了富有自己特色的扩展实现（诸如DHTML, XHR, IE扩展, css-ie, css-mozilla等），于是整个Web实现越来越混乱，一直到某天人们终于开始意识到Web标准的重要性了才开始重新走上正轨。
  
  
• 进入本世纪后，以Google提供的为代表的一些基于Ajax的“新”应用开始重新引起了大家的关注。Ajax是一个典型的新瓶装旧酒的例子，一堆过时技术绝处逢生诞生了一个新的Web应用时代。正当传统的基于HTML渲染的Web表现层应用占据绝大部分江山的时候，另一个原来由Web动画发家的基于Flash渲染的应用来势凶猛，凭借其超强的用户体验和“无处不在”的Flash播放器，正以迅雷不及掩耳之势（Macromedia对Flash普及功不可没，而当时的Microsoft还在睡觉呢，对Flash的未来错误估计了）越来越受到了最广大人民群众的欢迎。自从Flash的接力棒从Macromedia手中传递到新的Adobe公司后，以Flex, Apollo为代表的新应用这股热浪有愈演愈烈之势。
  
  
• 大约在两三年前，可能由于在Web运作理念和表现层体验等方面的创新数量不断膨胀，为了和原来迂腐陈旧的老Web划清界限，有人把这些新的东西叫做“Web 2.0”（其实从技术角度上来说还是换汤不换药），自从那以后，便一发不可收拾，一系列冠以Web 2.0光环的应用如雨后春笋般呼之欲出，再加上风险投资的一路热捧，一场新革命就这样开始了。
  
  
• 当人们已经逐渐习惯于甚至离不开基于B/S的online Web应用时（犹以Gmail，Google Docs, Google Spreadsheets为例），抱怨的声音也慢慢多了起来，比如网络连接的客观问题（如自然地震）影响了重要资料的访问，网络的主观临时中断（如飞机起飞降落时）使得工作无法继续等等。在这样那样的抱怨过后，有人开始想念传统的桌面应用之不依赖于网络的特性了，比如Microsoft Outlook, Word, Excel。自然而然地，新的Web应用需求诞生了：用户希望接下来的Web应用既要有Gmail的online好处，又要具有像Outlook那样offline也可以继续工作的优势，但前提是客户端尽量不要装任何额外软件（当然浏览器和Flash播放器之类的除外）。
  

　　如今，种种迹象已经可以是我们感觉：对offline的支持，将很快成为Web应用的下一个技术热点了！记得去年早些时候我和周围朋友这样预测的时候，当中的绝大多数不以为然，摇头对我说：历史已经从C/S跨到B/S了，怎么可能再回过去呢？诚然，他们说的也对，历史是不可能回去的，但需求的升级会从历史发展中诞生新的技术应用，又有谁知道会不会再出来个B/S 2.0或者C/S 2.0呢？这样的例子已经屡见不鲜了。

　　文末，让我来列出以下几个值得关注的offline技术应用动向：

• Adobe Apollo
  
• Mozilla XULRunner
• Dojo Offline Toolkit
• Firefox 3 offline cache

　　另注：此类技术，似乎大都把重点放在了offline的cache存储机制上，而很少或者没有涉及复杂的offline业务逻辑（比如offline的业务规则引擎、业务数据同步机制等等）。这些尚未开发的领域会不会是下一个重点呢？因为一旦开了这个online/offline的口子，用户的需求总是会步步跟进的，这个的挑战无疑更加严峻，真是追求永无止尽啊……让我们拭目以待。

William Cui 崔伟毅

Ajax应用的新“爬虫”机制

　　伴随着以Ajax驱动为代表的所谓Web 2.0应用的大规模流行，一系列巨大的新挑战也开始加速降临到目前搜索引擎的头上，一个新“爬虫”机制的建立已迫在眉睫。究其原因，我尝试用简单的语言分析如下：

• Ajax应用颠覆了以往基于纯HTTP请求/响应协议的“爬虫”机制，即默认所有的页面资源都是直接由超级链接所触发并指向的，现有的“爬虫”只需模拟用户的超级链接请求并解析对应的响应页面，然后再分析页面内容、语义以及衍生的超级链接，以此进行“爬网”。

• 所谓Ajax，即Asychronous Javascript and XML，与以往应用的最大不同之处在于将超级链接驱动的请求/响应更多地改用了Javascript驱动的异步请求/响应。而对于现有的“爬虫”一般来说，它们对Javascript是缺乏语义理解的，它们很难再去模拟触发Javascript的异步调用并解析返回的异步回调逻辑和内容。

• 对于传统的Web应用“爬虫”来说，它们默认每个页面的DOM结构是相对静态不变的，而这个前提条件在新的Ajax应用中再次被颠覆，对于用户的操作，Javascript会对DOM结构进行大量地变动，甚至页面所有的内容都是通过Javascript直接从服务器端读取并动态绘制出来的。

　　对于以上的变化和新挑战，Shreeraj Shah在Infosec Writers上发表了一篇名为“Crawling Ajax-driven Web 2.0 Applications”的论文。

　　在文中，作者指出传统的“爬虫”引擎大都是协议驱动的，而新的“爬虫”引擎需要的是事件驱动。在新的引擎中，要做到事件驱动，需要考虑以下三大关键问题：

1. Javascript的交互分析和解释
2. DOM事件的处理和解释分发
3. 动态DOM内容语义的抽取
   

　　另外，作者使用了rbNarcissus, Watir和Ruby语言和工具对这些问题和可能的解决方案进行了演示。有兴趣的可以去细细品读，再此就不一一介绍了。

　　在新一代或者说下一代Web应用中，这个“爬虫”机制的问题除了在Ajax中存在之外，在其他的Flash/Flex以及WPF/E, XUL应用等也是普遍存在的。而前对于Flash/Flex来说，问题可能更为严重，因为所有的Actionscript代码是编译执行的，这个在效率提高的同时，又无疑带给了“爬虫”们更为不可思议的持续挑战！

　　最后，还是在大年初一祝各位朋友：

　　猪年
快乐！

William Cui 崔伟毅