Dec
10
在int32(64位机器则为int64)的范围内的证书作为数组索引来存储数据的话，
在php中，会自动将这种可以转换成int的字符串转换成int作为索引使用。
以下面这一段脚本的输出来说明这个问题：
在php中，会自动将这种可以转换成int的字符串转换成int作为索引使用。
以下面这一段脚本的输出来说明这个问题：
<?php
$arr = array(
123 => 'a',
'123' => 'b',
0123 => 'c',
'0123' => 'd',
);
var_dump($arr);
?>
输出：
array(3) {
[123]=>
string(1) "b" //第一个123的a消失了，却出来了一个b，说明"123"在索引中被当作int处理了，并覆盖了之前123索引对应的值
[83]=> //0123是八进制的83
string(1) "c"
["0123"]=> //字符串
string(1) "d"
}
$arr = array(
123 => 'a',
'123' => 'b',
0123 => 'c',
'0123' => 'd',
);
var_dump($arr);
?>
输出：
array(3) {
[123]=>
string(1) "b" //第一个123的a消失了，却出来了一个b，说明"123"在索引中被当作int处理了，并覆盖了之前123索引对应的值
[83]=> //0123是八进制的83
string(1) "c"
["0123"]=> //字符串
string(1) "d"
}
Nov
24
zz from http://hi.baidu.com/whuisland/blog/item/17ba47ce6920340993457e4b.html
我是一个硬盘。
在一个普普通通的台式机里工作。别人总认为我们是高科技白领，工作又干净又体面，似乎风光得很。也许他们是因为看到洁白漂亮的机箱才有这样的错觉吧。其实象我们这样的小台式机，工作环境狭迫，里面的灰尘吓得死人。每天生活死水一潭，工作机械重复。跑跑文字处理看看电影还凑活，真要遇到什么大软件和游戏上上下下就要忙的团团转，最后还常常要死机。
我是一个硬盘。
在一个普普通通的台式机里工作。别人总认为我们是高科技白领，工作又干净又体面，似乎风光得很。也许他们是因为看到洁白漂亮的机箱才有这样的错觉吧。其实象我们这样的小台式机，工作环境狭迫，里面的灰尘吓得死人。每天生活死水一潭，工作机械重复。跑跑文字处理看看电影还凑活，真要遇到什么大软件和游戏上上下下就要忙的团团转，最后还常常要死机。
Nov
22
不解释，就让你看得蛋疼。
#include <iostream>
using namespace std;
class T {
typedef void (T::*Tptr)(void);
Tptr p;
public:
void a() { cout << "a" << endl; }
void b() { cout << "b" << endl; }
void call(Tptr _p) {
p = _p;
(this->*p)();
}
};
int main() {
T t1;
t1.call(&T::a);
t1.call(&T::b);
return 0;
}
using namespace std;
class T {
typedef void (T::*Tptr)(void);
Tptr p;
public:
void a() { cout << "a" << endl; }
void b() { cout << "b" << endl; }
void call(Tptr _p) {
p = _p;
(this->*p)();
}
};
int main() {
T t1;
t1.call(&T::a);
t1.call(&T::b);
return 0;
}
Nov
22
丢失了3篇日志和5篇评论。
不过幸好，Google Reader非常称职地保存了我那两篇日志，所以还是恢复过来了，差一个成员函数指针的，现在补一下吧。
看来备份工作还是要多多注意啊！
不过幸好，Google Reader非常称职地保存了我那两篇日志，所以还是恢复过来了，差一个成员函数指针的，现在补一下吧。
看来备份工作还是要多多注意啊！
Nov
22
在EB的Hi群里大家聊到了CSRF攻击的问题。
关于CSRF攻击，网上资料很多，简单说几句：现在很多网站对提交的请求不检查来源，攻击者可以简单地构造一个页面，页面包含一个大小为0x0的iframe，内含一个修改管理员密码或者创建新特权用户或为现有用户提升权限的表单，当页面载入的时候由javascript控制该表单post到abc.com的某个页面。然后攻击者将此url发送给abc.com的管理员，引诱其点击，如果管理员此时已经登录，就会在管理员不知情的情况下获得权限。具体的原理，如果不很了解，建议先学习一下HTTP协议，重点是GET/POST，Cookie/Sessoin，Referer。解决的办法比如限制referer，或者增加页面校验码等。
看了一下这个Bo-blog(2.1.0)，居然没有这个检查。。。囧。想起2.1.1，这个版本推出挺久了，因为2.1.0有些BUG折磨了我挺久（最近解决了一个，下载的问题，还有一个是rss在google reader总是少一篇），于是就去下了新版本在本地搭起来。看了一下，发现没有什么大的改动，对CSRF的攻击也完全不设防。而且由于现在这个版本我自己改了好多地方，比如根据IP直接显示地址，以及评论留言的邮件通知等，如果升级了还得重新改，太麻烦，所以完全没有升级的动力。到Bo-blog的bbs去提了个BUG报告。Bo-Blog的更新实在太少。。
@1:00 p.s. 已经修改，增加了检查POST时的Referer，GET就不检查了，这个。。真不能检查。。验证码就先不做了，每个页面都要去加，真不爽。这时候觉得bo-blog统一入口的原则真好，改动只有一个地方，加了几行就OK~
关于CSRF攻击，网上资料很多，简单说几句：现在很多网站对提交的请求不检查来源，攻击者可以简单地构造一个页面，页面包含一个大小为0x0的iframe，内含一个修改管理员密码或者创建新特权用户或为现有用户提升权限的表单，当页面载入的时候由javascript控制该表单post到abc.com的某个页面。然后攻击者将此url发送给abc.com的管理员，引诱其点击，如果管理员此时已经登录，就会在管理员不知情的情况下获得权限。具体的原理，如果不很了解，建议先学习一下HTTP协议，重点是GET/POST，Cookie/Sessoin，Referer。解决的办法比如限制referer，或者增加页面校验码等。
看了一下这个Bo-blog(2.1.0)，居然没有这个检查。。。囧。想起2.1.1，这个版本推出挺久了，因为2.1.0有些BUG折磨了我挺久（最近解决了一个，下载的问题，还有一个是rss在google reader总是少一篇），于是就去下了新版本在本地搭起来。看了一下，发现没有什么大的改动，对CSRF的攻击也完全不设防。而且由于现在这个版本我自己改了好多地方，比如根据IP直接显示地址，以及评论留言的邮件通知等，如果升级了还得重新改，太麻烦，所以完全没有升级的动力。到Bo-blog的bbs去提了个BUG报告。Bo-Blog的更新实在太少。。
@1:00 p.s. 已经修改，增加了检查POST时的Referer，GET就不检查了，这个。。真不能检查。。验证码就先不做了，每个页面都要去加，真不爽。这时候觉得bo-blog统一入口的原则真好，改动只有一个地方，加了几行就OK~
Nov
19
引用
UBB内容为（开头那个下划线不需要加）：
[_table]
l | r | l | c | r
左对齐|右对齐|左对齐|<a href="javascript:alert(12345)">居中啦啦啦</a>|右对齐
1|23|456|7890[newline]1234|0000
abcd|efg|hi|[-]|j
1|[-]|[-]|1|1
[/table]
[_table]
l | r | l | c | r
左对齐|右对齐|左对齐|<a href="javascript:alert(12345)">居中啦啦啦</a>|右对齐
1|23|456|7890[newline]1234|0000
abcd|efg|hi|[-]|j
1|[-]|[-]|1|1
[/table]
效果：
| 左对齐 | 右对齐 | 左对齐 | <a href="javascript:alert(12345)">居中啦啦啦</a> | 右对齐 |
| 1 | 23 | 456 | 7890 1234 |
0000 |
| abcd | efg | hi | j | |
| 1 | 1 | 1 | ||
PHP代码：
function maketbl($str) {
$str = str_replace("<br/>", "\n", $str);
$str = str_replace("|", "|", $str);
$str = trim($str);
$lines = explode("\n", $str);
$firstline = explode("|", trim($lines[0]));
$conf = array();
foreach($firstline as $v) {
switch($v) {
case 'l':
$conf[] = 'left';
break;
case 'r':
$conf[] = 'right';
break;
case 'c':
$conf[] = 'center';
break;
default:
$conf[] = '';
}
}
$ncols = count($conf);
$nline = count($lines);
$ret = '<table cellspacing="0" cellpadding="3" border="1">'. "\n";
for ($i = 1; $i < $nline; $i++) {
$line = trim($lines[$i]);
if (empty($line)) continue;
$line = explode("|", $line);
$ret .= "<tr>\n";
$next = 1;
for ($j = 0; $j < $ncols; $j++) {
if ($line[$j] == "[-]") {
$next++;
continue;
}
$td = $line[$j];
//$td = htmlspecialchars($td);
$td = str_replace("[newline]", "<br/>", $td);
$ret .= <<<eot
<td align="{$conf[$j]}" colspan="{$next}">{$td}</td>
eot;
if ($line[$j] != "[-]") {
$next = 1;
}
}
$ret .= "</tr>\n";
}
$ret .= "</table>";
return $ret;
}
$str = str_replace("<br/>", "\n", $str);
$str = str_replace("|", "|", $str);
$str = trim($str);
$lines = explode("\n", $str);
$firstline = explode("|", trim($lines[0]));
$conf = array();
foreach($firstline as $v) {
switch($v) {
case 'l':
$conf[] = 'left';
break;
case 'r':
$conf[] = 'right';
break;
case 'c':
$conf[] = 'center';
break;
default:
$conf[] = '';
}
}
$ncols = count($conf);
$nline = count($lines);
$ret = '<table cellspacing="0" cellpadding="3" border="1">'. "\n";
for ($i = 1; $i < $nline; $i++) {
$line = trim($lines[$i]);
if (empty($line)) continue;
$line = explode("|", $line);
$ret .= "<tr>\n";
$next = 1;
for ($j = 0; $j < $ncols; $j++) {
if ($line[$j] == "[-]") {
$next++;
continue;
}
$td = $line[$j];
//$td = htmlspecialchars($td);
$td = str_replace("[newline]", "<br/>", $td);
$ret .= <<<eot
<td align="{$conf[$j]}" colspan="{$next}">{$td}</td>
eot;
if ($line[$j] != "[-]") {
$next = 1;
}
}
$ret .= "</tr>\n";
}
$ret .= "</table>";
return $ret;
}
Nov
19
博客出现这个问题很久了，一直懒得去整。
今天实在觉得不爽了，于是去看了一下blog的attachment.php
发现问题出在这一句：@header("Content-Type: {$contenttype}");
boblog是把附件的扩展名保留，然后用timestamp什么的作为文件名。
然后提供下载的时候自己把扩展名截出来，在自己的$MIMEType数组里找到对应的字符串放到$contenttype这里
我看了一下，也没啥问题，但是只要下载二进制文件就会发现下载下来的文件其实是原始数据被gzip压缩了的。
觉得很奇怪，就算把博客的gzip加速给关了还是有这个问题。
我想这应该是服务器做了手脚吧，强制开启gzip。
总之，注释了那句以后就OK了，原因暂时想不清楚，撂着。
如果有哪位大牛晓得原因，还望告知，多谢。
今天实在觉得不爽了，于是去看了一下blog的attachment.php
发现问题出在这一句：@header("Content-Type: {$contenttype}");
boblog是把附件的扩展名保留，然后用timestamp什么的作为文件名。
然后提供下载的时候自己把扩展名截出来，在自己的$MIMEType数组里找到对应的字符串放到$contenttype这里
我看了一下，也没啥问题，但是只要下载二进制文件就会发现下载下来的文件其实是原始数据被gzip压缩了的。
觉得很奇怪，就算把博客的gzip加速给关了还是有这个问题。
我想这应该是服务器做了手脚吧，强制开启gzip。
总之，注释了那句以后就OK了，原因暂时想不清楚，撂着。
如果有哪位大牛晓得原因，还望告知，多谢。
