新发 blog 用 FriendFeed 订阅再推送到 Twitter 有两个缺点:时延和墙。既然我的主机在墙外,为什么不直接用插件发呢?试试看 WordPress Tweeter,走 Twitter API,很好很强大。此文顺做测试。
突然体会到,iPad 放在 dock 上看,无比登对。 7 hours 46 minutes ago
新发 blog 用 FriendFeed 订阅再推送到 Twitter 有两个缺点:时延和墙。既然我的主机在墙外,为什么不直接用插件发呢?试试看 WordPress Tweeter,走 Twitter API,很好很强大。此文顺做测试。
Ultimate Tag Warrior 3 – 好像现在网上说得最多的就是这个标签插件了。昨天试了下,蛮不错的,不过有些地方还需要自己动手修改。今天花了点时间,大致上对所有的文章都加上了 tag ,然后废止 Category 。
以前我的 blog 里面很少出现 code 片段,那是因为 WordPress 默认情况下支持不好,而且我很懒,所以宁可什么也不做。
刚才安装了来自 coffee2code.com 的插件,貌似不错。我不喜欢在文章中语法高亮,以及什么行号,干净最好。
单此可用了,不过默认的编辑器上面的按钮只有 Code 没有 Pre 也没有 PreCode。于是编辑 /wp-includes/js/quicktags.js ,找到定义 code 按钮的那一行,照样画葫芦加了两个。回来再修订下 css ,这下满意了。
这是帮助创建和验证图片 Captcha 的插件。底层用的是 GD::SecurityImage 。
http://search.cpan.org/dist/Catalyst-Plugin-Captcha/lib/Catalyst/Plugin/Captcha.pm
又一次简化了常见的任务。呵呵,coool
用户认证,通常是用户提交密码原文,通过 HTTP 协议,发送到服务器。然后程序或者直接比对密码原文,或者按一定的不可逆算法编码后和系统中预存的密码比较。进一步,为了在传输层上能安全传递,通常会选择 https 协议加密传输,不过这需要服务器端的配置。
现在有另一种方法,在客户端对用户输入的密码加密,然后再发送到服务器。这个工作交给 JavaScript 来做,看这里:
http://pajhome.org.uk/crypt/md5/
提供了三种(MD4,MD5,SHA-1)三种加密算法的 js 实现。拿来用就是了,很简单。Yahoo! 在它的非 https 的相关登入页就使用了这些脚本。
好,回过头来看标题,新出来的一个 Catalyst 的用户认证后端,名字叫 CHAP 。那么什么是 CHAP 呢?Challenge Handshake Authentication Protocol ,hoho,我也是 Google 来的,明白了,是一种协议,而且是认证协议。这里有些关于具体实现的介绍。不过我还是关心如何在 Catalyst 里面使用,看文档:
大致上,由该模块负责生成所谓 Challenge 的字符串,输出登入页时,作为表单的隐含字段。用户填好密码后,由上面提到的 JS 库负责将密码原文和 Challenge 字符串相加后加密编码,然后发送该编码到服务器。该模块则提供相应的后端处理,你什么都不用管,照常用 $c->login 就是了。
在 Catalyst 邮件列表中看到有人提到了这个模块。不过我现在无法访问 search.cpan.org 。
这是个自动生成密码的模块。不过它生成的是可读的密码。就是说由若干简短常用的单词组成的密码。好处就是容易记忆。
以前看到过若干站点的验证图片使用的不是随机数字或字母,就是诸如“smallhat”,“bluecup”等简单易记的单词。现在可以直接拿来用了,呵呵。
Catalyst 本身就提供了 $c->res->redirect(“…”); 的用法。不过这个 redirect 是全局的。如果 /admin 那就 redirect 到 http://example.com/admin 。如果你的应用直接部署在域名的根路径下不会有问题。但如果你部署在 /myapp 下面的话 $c->res->redirect(‘/admin’) 会重定向到 http://example.com/admin 而非预期的 http://example.com/myapp/admin 。
于是有了 Catalyst::Plugin::Redirect 。
这回你可以用 $c->redirect() 来做。他封装了 $c->res->redirect();
当你给出的 url 是 http 开头的,或者不是 / 开头的 url 的话,直接交给 $c->res->redirect 来处理。但当给出的 url 是以 / 开头的话,则重新构造目标 url 。假设部署在 http://example.com/myapp/chunzi 下面,给出的 url 为 /admin ,则重定向到 /myapp/chunzi/admin 。
很简单,不过还是比较有用,其实完全可以放到 core 里面而不是作为一个 plugin ,呵呵。
看到 dev.catalyst.perl.org 中有两个新的 Plugin 。
Catalyst::Plugin::UploadProgress
上传文件还是和以前一样处理,在表单提交的时候,帮定一个 Ajax 请求,然后返回这个 Plugin 计算出来的上传进度。当然每次请求都有一个 upload_id ,通过它来识别相关的文件。返回的 view 是 c.progress 的相关数据,当然也可以根据这些数据自己作一个 bar 来展示(不断更新 bar 对象的宽度)。
Catalyst::Plugin::JSAN
刚认识了 JSAN 就看到了(其实就算之前看到也不会在意)。这个 Plugin 主要东西都在 Helper 里面。通过 script/myapp_create.pl JSAN 会在 script/ 下面生成一个 myapp_jsan.pl 的脚本。然后你可以通过这个脚本从 JSAN 上下载并安装到该项目的 [home]/root/static/js 目录中(如果环境变量 $ENV{JSAN_PREFIX} 没有设置的话)。
Catalyst 下面的 Plugin 总是那么简单。这个 Plugin 目标要对来自请求的所有参数进行 html 安全过滤或者代码清理。核心过滤使用了 HTML::Scrubber 模块,所以相关的 Plugin 配置也是迎合 HTML::Scrubber 的需要。
所谓安全,就是去掉 Javascript 代码,所谓干净,就是去掉 html 注释,并且仅仅允许使用若干指定的 html 标签。如果我们要做 CMS 并提供用户编辑 html 源文件的话,这个 Plugin 可以帮助我们简化安全过滤。只是它针对所有的请求参数,也就是 $c->req->params 都进行了这样的过滤,是不是会发生聪明人自作聪明多干活的事情呢?我宁愿在指定的参数上作这样的过滤。或许该模块作者要做的项目确保不会出现干扰问题,所以才写了这样的 Plugin 吧。
又冒出来一个 Plugin ,比较简单,目标是一次对多个传入 stash 的参数使用键值对的形式赋值。
原来这样写,比较罗索,
$c->stash->{param1} = 'value1'; $c->stash->{param2} = 'value2'; $c->stash->{param3} = 'value3';
现在可以简单点:
$c->set_stash( param => 'value' ); $c->set_stash( param1 => 'value1', param2 => 'value2', param3 => 'value3', );