Jun 14
IUSR咿咿呀呀 google, picasa, web
地址：http://picasaweb.google.com/，注册（或者是激活？）很简单，输入Google Account就成了。
界面还算简洁，和GMail、Google Reader的风格不太一致，但挺好看，Photo Chooser也很好玩。上传图片可以在浏览器里上传，也可以用新版的Picasa，下载地址：http://dl.google.com/picasa/picasaweb-setup-beta.exe。
让我很关心的还是空间和展示图片的限制问题，flickr的类似限制最近被很多人提出来，尤其是限制200张图片的问题。看了一下Picasaweb的Learn More，解释的好像不是太清楚，或者说是我还报着一点奢望……如下：
Storage: Each Picasa Web Albums account comes with 250MB of free storage space, or room to post and share approximately 1,000 wallpaper-sized photos (at 1600 pixels each). For $25.00 per year, users can get a subscription to an additional 6GB of storage – room to post and share approximately 25,000 photos.
也没说是不是每个月250M…啊我承认太贪心了，flickr每个月才给免费用户20M，不过日久天长每个月20M就很多了…
让我觉得好笑的是，picasaweb应该检查了HTTP Referer了，所以在非google.com域以外的地方都没法打开，这里的截图只好借flickr宝地一用了……
Technorati : google, picasaweb
Jun 13
IUSR咿咿呀呀 javascript, security, web
昨晚看到The Register上的一篇文章：JavaScript worm targets Yahoo!，一个以js编写的蠕虫，借助Yahoo! Webmail的漏洞快速蔓延起来。这次的蠕虫比较特殊，以往的跟浏览器、web扯上关系的病毒，大多利用的是浏览器自身的问题，而这次是完全利用的web应用的问题。
安全的确是无处不在，比如这个蠕虫，它并没有对用户的系统造成侵害，但会从用户的Webmail联系人中找到同样使用Yahoo! Webmail的人并将自身转发给他，这又符合对蠕虫的一般定义。虽然用户一旦关闭浏览器，蠕虫在其机器中的实体就会灰飞烟灭，看似不堪一击，但实际对这个web应用已经造成影响。将自身转发给其他人只是它蔓延的方式，如果这个蠕虫不停的转发或者向这个网站发出请求，网站很可能被一下子DoS掉。
我一向以拟人的角度来看病毒，所以觉得它们就像生物中的病毒一样，狠毒中透着伟大，为了自身的生存和复制，在很严苛的环境里不断蚕食着周围生命的某个部分。算了，反正我已经从一个梦想成为安全专家的人变成一个稍微爱好安全的普通小程序员。
Apr 16
IUSR咿咿呀呀 web
用了半个月了。如果让我选世界上最好的在线radio，我肯定会投Pandora一票。完全个性化选择的曲目，通过用户提交的歌曲或者艺术家，借
Music Genome Project为用户找到风格类似的歌曲，建立属于自己的多个statioin。
挺好玩的站，界面简单得不得了，全部操作都在一个Flash中完成。我记得我的第一个station是输入Yanni建起来的，还返回了几行文字描述了Yanni的音乐，我只记得好像提过弦乐比较丰富什么的。当然如果你觉得station里的某首歌和你的station的风格不太一致的话，可以提供feed back，至少可以选择一下“I don’t like it”。
Cool到家了，而且没有普通radio里那些扫兴的广告。
Apr 15
IUSR咿咿呀呀 web
浏览着Google Reader里面的新闻和blog，读着Gmail里看不完的新闻邮件，用Writely保存了一份论文提纲准备发给导师，在Google Calendar上大致做着下周的规划，同时一个最小化到Systray的FF打开着Pandora在放着音乐，wow。
Oops，我忘了在meebo.com上面登几个IM…
Apr 08
IUSR补充两句 web
刚收到Kiko.com的邮件，这个我第一个接触的在线日程管理网站总算是更新了一下。登陆进去看了看，最大的变化应该是添加了多标签操作功能，不同的功能，比如日程表、联系人、设置等等，打开之后被放置在不同的tab上，而不是覆盖掉原操作区域，和支持多标签浏览的浏览器的操作基本相同。众多在线Calendar服务网站的逐步完善，外加Google Calendar一直秘密beta却不知何时真正发布的不确定，在线Calendar服务大概就是众多web 2.0网站争食的下一个领域，或者，一场大战已经开始。
在Google Reader里乱翻，忽然发现Netvibes blog也放出新消息：Netvibes welcome anise, the new netvibes update。比较吸引我的新特性就是这个”multiple pages with tags”，也是由tab支撑的。跑去试了一下，没想到Firefox的CPU占用率一下子飙到50%–我的机器是双核CPU，也就是说平均一块逻辑CPU已经满载了–然后Firefox就失去响应了。今天急着睡觉，明天再仔细看看。
下午在各个feed聚合器里面转时还在想这个问题，像Bloglines这样使用比较传统的树形结构–或者说允许用户使用这种方式–来组织feed的做法越来越少了，流行的做法几乎都是平面形组织feed外加tag。毫无疑问tag有它自己的好处，最显著的一个好处我觉得是类似一种上下文无关的特性，不会造成信息分层过深。在我看来，tag和树形结构的非子结点表现的还是很类似的，只是几乎没有哪个站允许用户自己管理tag之间的关系，而一般都是由网站程序自动来处理，所以由feed层面上升到tag层面来看，feed聚合器组织feed的方式还是局限在平面形式。这引发了我的一个疑问：页面究竟该如何组织？Google Reader貌似试图通过Google深厚的技术实力为用户简化feed、tag以及文章之间的组织管理，用户只要在Google Reader页面左边的垂直滚动部分挑选感兴趣的文章拿来看就可以了，用起来好像连tag都比较多余–有时我都奇怪Google Reader中的tag是为了让用户自己标注、分类还是为了让Google Reader的后台程序来决定文章之间的相关度、相似度等等。Netvibes的做法和Google ig比较类似，也和很多应用widgets的桌面程序–比如Konfabulator–比较类似，feed以及其他功能区域被当作widgets一样在页面上布局，这自然也是另一种处理平面形组织feed的做法，但是问题随之而来：widgets一多起来，操作十分困难，不仅是找某个feed的时候把滚动条拖来拖去让人着急，而且处理widgets布局的工作也相当占用CPU资源，这样一来，几乎无法在一个页面上放置太多的widgets。现在问题看似有了解决方案了：tab。感觉上像是提供了类似树形结构中的第二层结点–根结点自然是无法操作的，而且大部分时间里根结点都是为了模型统一而虚构出的，比如页面本身。我记得平面形组织信息好像是web2.0概念号召的一种观念，只是感觉我在日常使用这些web应用的时候，总是不自觉的疑惑界面究竟该如何处理。tab的出现不是很激动人心的事情，基本上是把桌面软件的界面套用了一下，我所好奇的只是这种类似向树形结构转变的组织信息的方法与平面形式的组织方法在使用时的微妙差异。不知道tab可以走多远？
Jan 22
IUSR补充两句 security, web
俗话说，隔行如隔山，到了计算机这行就更夸张了，外人也许不明白，都是搞计算机的，怎么差别就那 么大呢？搞computer.software的不懂computer.hardware的还好理解，不过搞 computer.software.develop.*的不懂computer.software.security.*的在外人看来实在有些丢人，实 际上呢，谁有那个工夫
买了本好久不买了的《黑客防线》，翻了翻，发现现在的主流入侵方法（或者说，破坏方法）俨然已经是SQL注入了，各种文章也越来越流于介绍 NBSI、HDSI等等工具的使用方法，看了几篇文章，貌似除了穿插的截图不太一样，其他的都大致相同，跟一本使用手册一样。还有的人认为JSP+ Oracle就不会或者很难被注入，实际上大家都明白，纯粹的字符串拼接逻辑才是SQL注入的温床。
随着各种webapp爆发式地推出，webapp自身的安全越来越不容忽视了。以前我也鼓捣过SQL注入，那时的目的还是想以这种入侵方法作为 辅助，以拿到root或者Administrators组权限为最终目的，而现在，能打掉一个论坛、一个CMS就已经是高手了，而且确实，这些 webapp的价值对于网站所有者而言有时超过服务器系统的价值：服务器OS可以重装，但数据或者代码的损失可是不可估量的。更有甚者，已经出现了靠 webapp或者数据向受害一方勒索钱财的案例。一代不如一代。
看来觉得web层逻辑随便找个新手来搞的观念要改一改了，不只要精通html+javascript做客户端验证，服务器端的验证一样很重要， 还要明白图形验证码这样的需要两端验证的方法，而且不只是过滤字符串那么简单，还要涉及sql、hql、jdoql等等查询语言的语法验证etc.，大概 熟悉antlr势在必行了。
我以往的观点是除非系统的管理员权限失守，否则其他的入侵不算本事，赫赫，很单纯的从技术方面的考量。现在不行了，负责一些的话就要考虑自己参与的webapp上线后要真正为客户创造价值，而不是创造麻烦。
有时间要检查一下我们用的一个web层组件的代码了，如果丫也是搞字符串拼接的话（而且很可能就是这么搞的
），那除了几个hard code在配置文件里的的用于显示固定栏目内容的查询，其他的……
各位webapp developer同行也要注意了，不能抱着防君子不防小人的想法来对待安全问题了，因为在互联网上你不知道对方是个小人。
RSS
Recent Comments