蜗牛的壳
我行依我素 | 苦苦咸咸就是我 | Snailium的个人网站
一直苦于无法远程开启/终止 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 |
分类
用户
链接
归档
- 2010年2月 (2)
- 2010年1月 (1)
- 2009年12月 (3)
- 2009年11月 (4)
- 2009年10月 (6)
- 2009年9月 (4)
- 2009年8月 (4)
- 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月 (3)
- 2006年6月 (2)
- 2006年3月 (12)
- 2006年2月 (1)
- 2006年1月 (1)
- 2005年12月 (2)
- 2005年11月 (1)
- 2005年10月 (4)
- 2005年9月 (1)
信息
- 分类数量: 13
- 文章数量: 208
- 评论数量: 78
- 标签数量: 387
- 附件数量: 318
- 引用数量: 2
- 注册用户: 9
- 今日访问: 241
- 总访问量: 495307
- 程序版本: 1.6