PHPor 的Blog

关于XMLHttpRequest对302的处理

摘自： http://hi.baidu.com/erik168/item/41a5910c1eca0627a0312dd8

【未亲自测试，请斟酌参考】

javascript代码：

<script>
function getXHR() {
    return window.ActiveXObject ? 
        new ActiveXObject("Microsoft.XMLHTTP") : 
        new XMLHttpRequest();
}

var log = [];
var xhr = getXHR();
//xhr.open('get', '302local.php');
xhr.open('get', '302net.php');
xhr.onreadystatechange = function () {
    try {
        log.push('status:' + xhr.status + ';readyState:' + xhr.readyState);
    } catch (ex) {}
    if (xhr.readyState == 4)
    {
        alert(log.join('\n'));
    }
};
xhr.send(null);
</script>

function getXHR() {

return window.ActiveXObject ?

new ActiveXObject("Microsoft.XMLHTTP") :

new XMLHttpRequest();

}

var log = [];

var xhr = getXHR();

//xhr.open('get', '302local.php');

xhr.open('get', '302net.php');

xhr.onreadystatechange = function () {

try {

log.push('status:' + xhr.status + ';readyState:' + xhr.readyState);

} catch (ex) {}

if (xhr.readyState == 4)

{

alert(log.join('\n'));

}

};

xhr.send(null);

</script>

302local.php:
header(“Location:hello.php”);

302net.php:
header(“Location:http://www.baidu.com”);

测试浏览器：
IE7
Firefox3.5
Opera9.6
Safari4

结论：
1.在重定向到本域时，无论如何都无法获得302状态码，XMLHttpRequest对象会直接读取重定向资源的内容

Fx3.5 alert：
status:200;readyState:2
status:200;readyState:3
status:200;readyState:4

IE7 alert：
status:200;readyState:4

Safari4 alert：
status:200;readyState:2
status:200;readyState:3
status:200;readyState:4

Opera9.6 alert：
status:200;readyState:3
status:200;readyState:4

2.在重定向到其他域时：
Safari和Opera会哑掉
IE会问你“可能导致安全风险，是否继续”，是的话取得status是200，否的话取得status是0
Firefox会获得302的status

Fx3.5 alert：
status:302;readyState:2
status:302;readyState:4

IE7 alert：
status:200;readyState:4
or
status:0;readyState:4

以crond为例学习后台程序的经典写法

这里了解一下对于一个后台程序是如何处理标准输入、标准输出、标准错误的。

vixie-cron-4.1

switch (fork()) {
case -1:
    log_it("CRON",getpid(),"DEATH","can't fork");
    exit(0);
    break;
case 0:
    /* child process */
    (void) setsid();
    if ((fd = open(_PATH_DEVNULL, O_RDWR, 0)) >= 0) {
        (void) dup2(fd, STDIN);
        (void) dup2(fd, STDOUT);
        (void) dup2(fd, STDERR);
        if (fd != STDERR)
            (void) close(fd);
    }
    log_it("CRON",getpid(),"STARTUP",CRON_VERSION);
    break;
default:
    /* parent process should just die */
    _exit(0);
}

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

switch (fork()) {

case -1:

log_it("CRON",getpid(),"DEATH","can't fork");

exit(0);

break;

case 0:

/* child process */

(void) setsid();

if ((fd = open(_PATH_DEVNULL, O_RDWR, 0)) >= 0) {

(void) dup2(fd, STDIN);

(void) dup2(fd, STDOUT);

(void) dup2(fd, STDERR);

if (fd != STDERR)

(void) close(fd);

}

log_it("CRON",getpid(),"STARTUP",CRON_VERSION);

break;

default:

/* parent process should just die */

_exit(0);

}

、

Attaching Android platform source in Eclipse

问题

按照adroid.com 来配置的adroid开发环境，其它都很顺利，唯独无法查看adroid的源代码，现象如下：

解决办法

我的android-sdk的安装路径： D:\Android\android-sdk 我已经通过adt工具下载了android-16的源代码，默认放在目录： D:\Android\android-sdk\sources\android-16 中的，现在把该目录移动（或复制）到 D:\Android\android-sdk\platforms\android-16\sources 即可，需要重启eclipse

原因： adroid不允许加载项目外部的源代码，也因此，在windows上也不能使用“快捷方式”来把D:\Android\android-sdk\platforms\android-16\sources 快捷方式到 D:\Android\android-sdk\sources\android-16

不明白的是： 1. eclipse的android开发插件是官方开发的 2. android-sdk-manager也是官方开发的 3. 为什么就不能把源代码下载到能加载的目录呢？

参考资料：

http://blog.163.com/fan_jianglong@126/blog/static/561705362012574356790/

http://android.opensourceror.org/2010/01/18/android-source/

关于证书的一些概念

根证书

在密码学和计算机安全领域中，根证书是未被签名的公钥证书或自签名的证书。根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。

从技术上讲，证书其实包含三部分，用户的信息，用户的公钥，还有CA中心对该证书里面的信息的签名，要验证一份证书的真伪（即验证CA中心对该证书信息的签名是否有效），需要用CA 中心的公钥验证，而CA中心的公钥存在于对这份证书进行签名的证书内，故需要下载该证书，但使用该证书验证又需先验证该证书本身的真伪，故又要用签发该证书的证书来验证，这样一来就构成一条证书链的关系，这条证书链在哪里终结呢？答案就是根证书，根证书是一份特殊的证书，它的签发者是它本身，下载根证书就表明您对该根证书以下所签发的证书都表示信任，而技术上则是建立起一个验证证书信息的链条，证书的验证追溯至根证书即为结束。所以说用户在使用自己的数字证书之前必须先下载根证书。

自签名证书

自签名证书是其签发者（签名者）与主题（其公共密钥由该证书进行验证的实体）相同的证书

未签名证书与自签名证书

二者都无法校验其身份的真实性
自签名证书通过“用户确认”（信任该颁发结构，其实还是自己）可以完成其校验流程；未签名证书不知道颁发机构是谁，就算知道是谁，也因为没有签名而无法校验。

证书链

证书链由两个环节组成—信任锚（CA 证书）环节和已签名证书环节。自我签名的证书仅有一个环节的长度—信任锚环节就是已签名证书本身。

证书链可以有任意环节的长度，所以在三节的链中，信任锚证书CA 环节可以对中间证书签名；中间证书的所有者可以用自己的私钥对另一个证书签名。CertPath API 可以用来遍历证书链以验证有效性，也可以用来构造这些信任链。

Web 浏览器已预先配置了一组浏览器自动信任的根 CA 证书。来自其他证书授权机构的所有证书都必须附带证书链，以检验这些证书的有效性。证书链是由一系列 CA 证书发出的证书序列，最终以根 CA 证书结束。

证书最初生成时是一个自签名证书。自签名证书是其签发者（签名者）与主题（其公共密钥由该证书进行验证的实体）相同的证书。如果拥有者向 CA 发送证书签名请求 (CSR)，然后输入响应，自签名证书将被证书链替换。链的底部是由 CA 发布的、用于验证主题的公共密钥的证书（回复）。链中的下一个证书是验证 CA 的公共密钥的证书。通常，这是一个自签名证书（即，来自 CA、用于验证其自身的公共密钥的证书）并且是链中的最后一个证书。

在其他情况下，CA 可能会返回一个证书链。在此情况下，链的底部证书是相同的（由 CA 签发的证书，用于验证密钥条目的公共密钥），但是链中的第二个证书是由其他 CA 签发的证书，用于验证您向其发送了 CSR 的 CA 的公共密钥。然后，链中的下一个证书是用于验证第二个 CA 的密钥的证书，依此类推，直至到达自签名的根证书。因此，链中的每个证书（第一个证书之后的证书）都需要验证链中前一个证书的签名者的公共密钥。

代码签名

http://baike.baidu.com.cn/view/480143.htm

神奇的“粘住位”

教材中关于“粘住位”的解释：

==========================================

UNIX环境高级编程

文件和目录

文件的粘住位 ( S _ I S V T X )，在U N I X的早期版本中，有一位被称为粘住位（sticky bit）。如果一个可执行程序文件的这一位被设置了，那么在该程序第一次执行并结束时，该程序正文的一个文本被保存在交换区。(程序的正文部分是机器指令部分)这使得下次执行该程序时能较快地将其装入内存区。其原因是：在交换区，该文件是被连续存放的，而在一般的 U N I X文件系统中，文件的各数据块很可能是随机存放的。对于常用的应用程序，例如文本编辑程序和编译程序的各部分常常设置它们所在文件的粘住位。
自然，对交换区中可以同时存放的设置了粘住位的文件数有一定限制，以免过多占用交换区空间，但无论如何这是一个有用的技术。因为在系统再次自举前，文件的正文部分总是在交换区中，所以使用了名字“粘住” 。后来的U N I X版本称之为保存 -正文位（saved-text bit），因此也就有了常数 S _ I S V T X。现今较新的U N I X系统大多数都具有虚存系统以及快速文件系统，所以不再需要使用这种技术。S V R 4和4 . 3 + B S D中粘住位的主要针对目录。如果对一个目录设置了粘住位，则只有对该目录具有写许可权的用户并且满足下列条件之一，才能删除或更名该目录下的文件：
· 拥有此文件。
· 拥有此目录。
· 是超级用户。
目录/ t m p和/ v a r / s p o o l / u u c p p u b l i c是设置粘住位的候选者—这两个目录是任何用户都可在其中创建文件的目录。这两个目录对任一用户 (用户、组和其他)的许可权通常都是读、写和执行。但是用户不应能删除或更名属于其他人的文件，为此在这两个目录的文件方式中都设置了粘住位。

==========================================

对于目录 /test/ 来讲，如果读写权限为755，属主为test:test , 则其它用户（如：test2）将无法在该目录下创建（或删除）文件或目录，如果该目录下存在一个读写权限为666的文件，则 test2 可以修改该文件的内容，不能删除该文件：如果要允许test2也能在该目录下创建文件，则test2也必将可以删除该目录下的任何文件（虽然可能无法读写文件）。

对于/tmp 这个特殊的目录来讲，即允许任何人创建和删除文件，又不允许删除不是自己的文件，按照上述的权限控制逻辑是做不到的，于是“粘住位”就有了用武之地了。这样就达到了允许创建、删除文件，但是无法删除别人的文件，每个人把文件属性设置后600就会很安全了，大家工作在同一个目录下，而且不能相互读写以及删除，多么神奇的想法啊。

给目录设置粘住位，达到/tmp 这样的效果；给文件设置“粘住位”呢？注意： linux （仅限linux）忽略文件的“粘住位”

设置“粘住位”

chmod 1777 the_dir

TCP segment of a reassembled PDU

参考资料：

http://blog.163.com/hlz_2599/blog/static/142378474201151933643431/

ssl协议说明

1. 下面这句话怎么解释？

Note: According to current US export law, RSA moduli larger than 512
   bits may not be used for key exchange in software exported from the
   US.  With this message, larger RSA keys may be used as signature-only
   certificates to sign temporary shorter RSA keys for key exchange.

Note: According to current US export law, RSA moduli larger than 512

bits may not be used for key exchange in software exported from the

US. With this message, larger RSA keys may be used as signature-only

certificates to sign temporary shorter RSA keys for key exchange.

为什么超过512位只允许用于签名而不允许用户密钥交换？难道超过512位用于密钥交换不是更加安全吗？

2. Server Key Exchange Message 的作用

 The server key exchange message is sent by the server if it has no
   certificate, has a certificate only used for signing (e.g., DSS [<a title="&quot;Digital Signature Standard&quot;" href="http://tools.ietf.org/html/rfc6101#ref-DSS">DSS</a>]
   certificates, signing-only RSA [<a title="&quot;A Method for Obtaining Digital Signatures and Public-Key Cryptosystems&quot;" href="http://tools.ietf.org/html/rfc6101#ref-RSA">RSA</a>] certificates), or FORTEZZA KEA
   key exchange is used.  This message is not used if the server
   certificate contains Diffie-Hellman [<a title="&quot;New Directions in Cryptography&quot;" href="http://tools.ietf.org/html/rfc6101#ref-DH1">DH1</a>] parameters.

   Note: According to current US export law, RSA moduli larger than 512
   bits may not be used for key exchange in software exported from the
   US.  With this message, larger RSA keys may be used as signature-only
   certificates to sign temporary shorter RSA keys for key exchange.

The server key exchange message is sent by the server if it has no

certificate, has a certificate only used for signing (e.g., DSS [<a title=""Digital Signature Standard"" href="http://tools.ietf.org/html/rfc6101#ref-DSS">DSS</a>]

certificates, signing-only RSA [<a title=""A Method for Obtaining Digital Signatures and Public-Key Cryptosystems"" href="http://tools.ietf.org/html/rfc6101#ref-RSA">RSA</a>] certificates), or FORTEZZA KEA

key exchange is used. This message is not used if the server

certificate contains Diffie-Hellman [<a title=""New Directions in Cryptography"" href="http://tools.ietf.org/html/rfc6101#ref-DH1">DH1</a>] parameters.

Note: According to current US export law, RSA moduli larger than 512

bits may not be used for key exchange in software exported from the

US. With this message, larger RSA keys may be used as signature-only

certificates to sign temporary shorter RSA keys for key exchange.

如果server没有证书，或者server的证书只用于签名（如DSS证书，或只用于签名的RSA证书），这时候server端就会生成一对临时的公私钥，用户密钥交换。

3. 客户端是如何确认sever端的身份的？

首先，通过证书的校验机制，验证证书的有效性；然后，使用证书公钥

4. 共享密钥的交换过程是怎样的？

5. 关于ssl的sessionid的概念？

如果sessionid标识的session在server端没有过期的话，就不需要再校验证书，协商密钥套件了。（如果server端的配置有问题的话，你会发现依然有证书校验的过程），该sessionid在客户端一般不会落地的，比如：重启浏览器后该sessionid就消失了

6. ssl与tls的关系

ietf对ssl做了标准化，在ssl3.0的基础上定义了tls1.0 规范

7. curl -H “Host: login.sina.com.cn” -v “https://10.54.38.18/httpsdetector.php”

curl 不会使用-H指定的域名来和返回的证书做匹配的。也不会把ip作为server_name 写到ssl的扩展字段中，如果使用

curl “https://login.sina.com.cn/httpsdetector.php”

则会把 login.sina.com.cn 写到 ssl的server_name 的扩展字段中的

参考资料：

http://rrsongzi-gmail-com.iteye.com/blog/603015

http://wenku.baidu.com/view/1f64701a10a6f524ccbf8595.html

单个IP上配置多个HTTPS虚拟主机的实现

缘起

一度以为虚拟主机的配置是和http协议中的“Host”请求头有密切关系的，而ssl工作在http的下一层协议,先于http建立连接的，而在建立连接的时候是需要和“Host”相对应的证书的，再而且该证书在server端是配置在虚拟主机中的，所以，单个IP无法配置多个证书提供多个https的服务的，今天在阅读ssl的rfc时，一边也分析了ssl的握手过程，才发现host信息完全可以通过ssl的扩展字段告知server端该提供哪一份证书，于是，去百度google了一下，果然是可以这么做的。

参考资料

http://coolerfeng.blog.51cto.com/133059/91736/

http://zhumeng8337797.blog.163.com/blog/static/1007689142011023102443424/ （参考其中的mod_gnutls）

http://tools.ietf.org/html/rfc6101

http://www.ietf.org/rfc/rfc3546.txt （参考其中的 server_name)

各大网站登录方式比较

sohu

优先使用https登录方式，失败后再尝试http
密码加密方式： md5

腾讯

根本不使用https
密码加密方式和sina基本完全一样

js的数组排序算法

关于XMLHttpRequest对302的处理

以crond为例学习后台程序的经典写法

Attaching Android platform source in Eclipse

问题

解决办法

关于证书的一些概念

根证书

自签名证书

未签名证书与自签名证书

证书链

代码签名

神奇的“粘住位”

教材中关于“粘住位”的解释：

UNIX环境高级编程

文件和目录

TCP segment of a reassembled PDU

ssl协议说明

单个IP上配置多个HTTPS虚拟主机的实现

缘起

相关概念

参考资料

各大网站登录方式比较

sohu

腾讯