我行依我素 | 苦苦咸咸就是我 | Snailium的个人网站
一直苦于无法远程开启/终止 My Book World Edition 上的服务,有时候在公司发现 Transmission 崩溃却无法重启。终于昨晚忍无可忍,自行在管理后台加了一个服务管理标签。
值得一提的是,Western Digital 的后台做得实在不怎么样,很难扩展。为了做这个 mod,改动近 10 个文件,添加 5 个文件。而且需要重启 lighttped 才能生效。
目前只做了 Transmission 一项。本来想加上 TwonkyMedia,但是想想远程并不需要管理 Twonky。
闲来无事,研究了一下 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 |
开始还满怀信心的打算拿 Perl 写一个文件上传管理程序,可是在写完了登陆部分之后就泄气了。原因很简单,服务器不支持 CGI::Session,而我又不想花时间去研究 Perl Cookie。
其中登陆部分采用了《突发奇想,小改动解决安全问题》其中的方法。
看来要重操 PHP 旧业了……
这几天一直在琢磨用 Perl CGI 架设网站,正好在网上看到了一篇关于 CGI 安全的文章,里面提到了数据库注入和远程执行等等安全问题。也就是说,比较安全的方法是屏蔽一系列特殊字符(比如说,管道“|”、引号“" '”、斜线“/”等等)。今天偶然间突发奇想,如果换一种思路,不需要过滤特殊字符也能做到脚本安全。
具体方法如下。(假设:用户名与密码存在 user 表中,密码用 md5 加密)
由于 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 |