蜗牛的壳
me =~ s/nai/liu/m;
服务器架好之后，就想着怎样把所有的服务统一管理。My Book 上的 Transmission，主机上的 eMule，还有 MiPony，这些程序都带有用于远程控制的 WebUI。但是这些服务分散在内网的多个机器上，需要设置逆向代理才能从外网统一访问。
首先根据教程安装上 Rewrite 2.0 和 Application Request Routing 2.0。但是，在设置 Rewrite Rule 的之后，远程访问总是报告 404 文件未找到。后来终于找到原因，在 IIS 7.5 上需要用“服务器场（Server Farm）”来引导请求指向。
首先，在新建一个服务器场，就叫做 eMule。这个服务器场只有一个服务器。（由于我的 eMule 远程控制端口开在 5000，所以要先把 httpPort 改成 5000，再点“添加”）
然后，在 Inbound Rewrite Rule 里面选择“指向直服务器场”。
逆向代理的好处不仅仅是中心管理，而且还能使用 SSL 加密连接和 IIS 集成的用户验证，这样可以使远程管理更加安全。
后记：有些时候 Geek == Freak（翻译成中文就叫“沙比”）。本来也想把 uTorrent WebUI 集成进来的，结果发现 uTorrent 的用户验证没办法关掉，而 IIS 7.5 又需要另外一套验证。uTorrent 官网上有很多人建议把用户验证作为可选项，可是得到的回复都是“为了安全起见，俺们不会那么做。否则小白的机器就会被别人控制，所有下载都会被删光光……” 就一个简单的明文验证还叫安全？难道坏蜀黍们就不会嗅探远程密码、得到控制权限么？做个可选项，并且默认启用会死？
2011/02/06 更新：
终于把 uTorrent 也给设置好了。这里需要耍个小聪明，因为我的服务器使用的是简单密码登录，而 ARR 在做逆向代理的时候，会把 HTTP 头的验证部分也传递过去，所以只需要在 uTorrent 里面把用户名/密码设置成跟登录服务器的一致就可以了。
另外，uTorrent 2.0 以上版本的 WebUI 加入了 Auth Token，这个“安全巧妙”的设计却使用了一种非常傻缺的方法来实现：在 javascript 脚本里面不断请求 http://{host}/gui/?token= 或者http://{host}/gui/token.html。我的转向目录设置为 /utorrent/，所以请求 /gui/ 下面的东西 IIS 理所当然地回复 404 文件未找到。
解决方法也很麻烦，要在 uTorrent 程序配置路径中找到 webui.zip，用 WinZip/WinRAR 将里面的 webui.js.gz 解出来，再用 gunzip 解出 webui.js，把里面的 urlBase（在 3.8.0 中是 guiBase）变量强制改为“./”，再用 gzip 封包，然后替换到 webui.zip 中。到这里还没完，还需要重新启动 uTorrent 才能使更改生效！
最后，终于把 uTorrent 也整合到中心管理中了。
2011/02/06 另更新：
如果在根节点设置 Rewrite Rule，则必须使用服务器场。如果在某一站点节点设置 Rewrite Rule，可以不使用服务器场，直接填写 http://server-address/service-url 即可。
- 标签：iis, arr, rewrite, reverse proxy
一直苦于无法远程开启/终止 My Book World Edition 上的服务，有时候在公司发现 Transmission 崩溃却无法重启。终于昨晚忍无可忍，自行在管理后台加了一个服务管理标签。
值得一提的是，Western Digital 的后台做得实在不怎么样，很难扩展。为了做这个 mod，改动近 10 个文件，添加 5 个文件。而且需要重启 lighttped 才能生效。
目前只做了 Transmission 一项。本来想加上 TwonkyMedia，但是想想远程并不需要管理 Twonky。
- 标签：mbwe, service, management, page, mod
闲来无事，研究了一下 Sablog 模板和 .htaccess，顺便给自己的网站加上了自定义错误页面。参见以下链接：
http://www.snailium.net/error-400.html
http://www.snailium.net/error-401.html
http://www.snailium.net/error-403.html
http://www.snailium.net/error-404.html
http://www.snailium.net/error-500.html
| 100 系列（信息） | |
| 100 | Continue（客户端可以继续发送未发完的请求） |
| 101 | Switch Protocals（服务端/客户端所使用的协议不一致） |
| 200 系列（成功） | |
| 200 | OK（成功） |
| 201 | Created（已按请求创建新资源） |
| 202 | Accepted（请求已被接受） |
| 203 | Non-Authoritative Information（从第三方获取的信息） |
| 204 | No Content（服务端没有可返回的数据） |
| 205 | Reset Content（客户端需重置请求内容） |
| 206 | Partial Content（服务端返回部分数据） |
| 300 系列（重定向） | |
| 300 | Multiple Choices（多个资源可用） |
| 301 | Moved Permanently（资源已被移动） |
| 302 | Found（临时在其他地址找到相应资源） |
| 303 | See Other（在其他地址找到相应资源） |
| 304 | Not Modified |
| 305 | Use Proxy |
| 306 | (Unused) |
| 307 | Temporary Redirect |
| 400 系列（错误） | |
| 400 | Bad Request |
| 401 | Unauthorized |
| 402 | Payment Required |
| 403 | Forbidden |
| 404 | Not Found |
| 405 | Method Not Allowed |
| 406 | Not Acceptable |
| 407 | Proxy Authentication Required |
| 408 | Request Timeout |
| 409 | Conflict |
| 410 | Gone |
| 411 | Length Required |
| 412 | Precondition Failed |
| 413 | Request Entity Too Large |
| 414 | Request-URI Too Long |
| 415 | Unsupported Media Type |
| 416 | Requested Range Not Satisfiable |
| 417 | Expectation Failed |
| 500 系列（服务器错误） | |
| 500 | Server Internal Error |
| 501 | Not Implemented |
| 502 | Bad Gateway |
| 503 | Service Unavailable |
| 504 | Gateway Timeout |
| 505 | HTTP Version Not Supported |
- 标签：http, status code, 状态
Perl CGI 初体验
时间：20:15:28 作者：snailium开始还满怀信心的打算拿 Perl 写一个文件上传管理程序，可是在写完了登陆部分之后就泄气了。原因很简单，服务器不支持 CGI::Session，而我又不想花时间去研究 Perl Cookie。
- #!/usr/bin/perl -w
- # ***********************************************
- # * Handle User Login *
- # ***********************************************
- use strict;
- use DBI;
- #use CGI::Session;
- use CGI;
- use Digest::MD5 qw(md5_hex);
- # Get the CGI form data
- my $cgi = new CGI;
- # Fetch login username and password
- my $user_name = $cgi->param('username');
- my $user_pass = $cgi->param('password');
- $user_name =~ s/(?:\012\015|\012|\015)//g;
- $user_pass =~ s/(?:\012\015|\012|\015)//g;
- $user_pass = md5_hex($user_pass);
- my $user_login = 0
- require "config.pm"
- # Import Database configuration
- our $db_host;
- our $db_use;
- our $db_user;
- our $db_pass;
- our $db_table;
- # Connect to database
- my $db_conn = DBI->connect("DBI:mysql:database=$db_use;host=$db_host","$db_user","$db_pass", {'RaiseError' => 1});
- print "Location: /error-503\n\n" unless $db_conn;
- # Check if we have such password in database
- my $sql = $db_conn->prepare("SELECT username FROM `$db_table` WHERE user_password='$user_pass'");
- $sql->execute() or print "Location: /error-503\n\n";
- # Process query result
- while(my @result = $sql->fetchrow_array()) {
- if($user_name eq $result[0]) {
- # Here we go. A user is found with the same username and password.
- $user_login = 1
- last;
- }
- }
- # Disconnect from database
- $db_conn->disconnect();
- # Not pass user check? Kick it out!
- print "Location: /error-401\n\n" unless $user_login;
- # User check successful! Log it in!
- print "Content-type: text/plain\n\nYes !";
- exit(0);
其中登陆部分采用了《突发奇想，小改动解决安全问题》其中的方法。
看来要重操 PHP 旧业了……
这几天一直在琢磨用 Perl CGI 架设网站，正好在网上看到了一篇关于 CGI 安全的文章，里面提到了数据库注入和远程执行等等安全问题。也就是说，比较安全的方法是屏蔽一系列特殊字符（比如说，管道“|”、引号“" '”、斜线“/”等等）。今天偶然间突发奇想，如果换一种思路，不需要过滤特殊字符也能做到脚本安全。
具体方法如下。（假设：用户名与密码存在 user 表中，密码用 md5 加密）
- $username = http_get("username"); // Get username from browser
- $password = http_get("password"); // Get password from browser
- $password = md5($password); // Make md5 hash for password
- $mysql->connect(); // Connect to database
- // Get all users that have this password
- $rows = $mysql->query("SELECT username FROM `user` WHERE password='$password'");
- // If no one match, must be username/password problem
- while($r = $rows->next()) {
- if($r->username == $username) login_success();
- }
- die("Username/password incorrect!");
由于 md5 hash 不包括任何特殊字符，所以这段脚本对数据库无害。
优点总结：由于传递给数据库的字符串当中不包括任何特殊字符，因此没有任何注入危险。
缺点总结：一般来说，用户数据表都是拿用户名做索引，所以按密码查询效率相对低一些。但是考虑到用户登录的频繁程度，这个缺点就无所谓了。
最近在折腾自己的网站和DV站，打算装个相册上去。
终于找到相册程序了，但都是GB2312编码的。鉴于网站都是UTF-8的，只好用UltraEdit手工转码。
但是，转成UTF-8的程序上传到服务器之后却频频白屏。setcookie和header均出错。这肯定是在header之前有数据输出。
用IE查看源代码，一无所获。用FireFox查看源代码，发现有6个无法显示的空字符。这才想起来是不是编码的问题。
Google了一下，UTF-8用BOM（Byte Order Mark，字节顺序标记）标记字节顺序。BOM一般加在文件头，长度三字节（EF BB BF）。如果程序发现BOM，则自动按照UTF-8处理。
问题就出在BOM上面。PHP是不支持BOM的，所以PHP在处理文件的时候会把BOM直接输出，也就导致了header之前存在输出，从而setcookie和header不起作用。
知道问题，解决起来也不难了。用UltraEdit将文件保存为“UTF-8 无 BOM”就行了。
| 日 | 一 | 二 | 三 | 四 | 五 | 六 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
分类
用户
链接
归档
- 2012年1月 (1)
- 2011年10月 (2)
- 2011年9月 (2)
- 2011年8月 (1)
- 2011年7月 (2)
- 2011年4月 (2)
- 2011年3月 (4)
- 2011年2月 (6)
- 2011年1月 (9)
- 2010年12月 (7)
- 2010年11月 (5)
- 2010年10月 (15)
- 2010年9月 (7)
- 2010年8月 (4)
- 2010年7月 (2)
- 2010年6月 (8)
- 2010年5月 (5)
- 2010年4月 (4)
- 2010年3月 (5)
- 2010年2月 (2)
- 2010年1月 (1)
- 2009年12月 (3)
- 2009年11月 (4)
- 2009年10月 (6)
- 2009年9月 (4)
- 2009年8月 (5)
- 2009年7月 (9)
- 2009年6月 (4)
- 2009年5月 (4)
- 2009年4月 (8)
- 2009年3月 (9)
- 2009年2月 (11)
- 2009年1月 (4)
- 2008年12月 (7)
- 2008年11月 (11)
- 2008年10月 (2)
- 2008年7月 (4)
- 2008年6月 (3)
- 2008年5月 (7)
- 2008年4月 (4)
- 2008年3月 (11)
- 2008年2月 (3)
- 2007年12月 (1)
- 2007年11月 (1)
- 2007年10月 (1)
- 2007年9月 (2)
- 2007年7月 (7)
- 2007年6月 (9)
- 2007年5月 (3)
- 2007年4月 (6)
- 2007年3月 (6)
- 2007年2月 (5)
- 2006年12月 (3)
- 2006年11月 (3)
- 2006年10月 (5)
- 2006年9月 (4)
- 2006年6月 (3)
- 2006年3月 (12)
- 2006年2月 (1)
- 2006年1月 (2)
- 2005年12月 (2)
- 2005年11月 (2)
- 2005年10月 (5)
- 2005年9月 (1)
- 2005年5月 (1)
信息
- 分类数量: 15
- 文章数量: 307
- 评论数量: 114
- 标签数量: 556
- 附件数量: 510
- 引用数量: 0
- 注册用户: 12
- 今日访问: 369
- 总访问量: 778232
- 程序版本: 1.6
加拿大中文电话
- CIBC
1-888-298-8822 - TD Canada Trust
1-800-387-2828 - HSBC
1-888-310-4722 - Scotia Bank
1-800-830-8080 - RBC Royal Bank
1-888-769-2598 - Rogers TV
1-800-787-7953
1-866-406-7239 - Rogers Wireless
1-800-828-9828
or *2288 - Fido
1-866-888-3436 - Bell Home Phone
1-800-715-1888 - Bell ExpressVu
1-888-759-3474 - UPS Delivery
1-800-233-8133