PHPor 的Blog

sohu

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

腾讯

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

主要js文件：

http://imgcache.qq.com/ptlogin/ver/10013/js/xui.js?v=10007

建议将该文件格式化后分析，可以通过fiddler 自动响应的功能使用格式化的文件，然后在函数： onQloginSelect 上设置断点，然后跟踪下去就行了。

关键技术：

1. 浏览器插件，IE下使用 ActiveObjectX ，其它浏览器使用embed

2. 登录请求通过对域名的限制来实现

QQ登录插件文件：

C:\Program Files\Tencent\QQ\Bin\TXSSO\bin\npSSOAxCtrlForPTLogin.dll

分析的结果和下面文件中描述的一致，所以不再细说。曾经分析过，只是没有记录，都给忘了，这里记录一下。

相关参考资料： 搜索关键字：“embed application nptxsso”

http://1.lanz.sinaapp.com/?p=152

http://www.dewen.org/q/1027

http://www.udpwork.com/item/7598.html

学到的一些知识：

——————————————– 摘自上面参考资料

原来，QQ 使用了历史很悠久的 NPAPI（Netscape Plugin Application Programming Interface）接口。NPAPI 几乎支持所有主流浏览器，包括 FireFox、Chrome、Opera（IE 从 5.5 后停止支持 NPAPI，转而使用 ActiveX）。

打开 chrome://plugins/ 我们可以发现自动登录的有关插件，而在路径 C:\Program Files (x86)\Common Files\Tencent\TXSSO 下就可以找到关于 SSO 的相关动态链接库。

np 插件一般命名都会加np前缀 如 QQ 的这个 npSSOAxCtrlForPTLogin.dll，只要按照标准的写法，放在浏览器会加载的地方，用的时候写个标签就可以在 js 里面调用了。于是跨浏览器（无视 IE）的插件开发变得相当可行。运行在 NPAPI 插件中的代码拥有当前用户的所有权限，不在沙箱中运行，所以它的扩展程序在被 Chrome 网上应用店接受前要求人工审核。

————————————————–

注意“插件”与“扩展”的区别，这里说的是“插件”； 上面提到的“人工审核”机制是怎么做到不审核就无法使用的呢？ 在浏览器上通过都需要该浏览器的厂商审核通过？

问题：

Linux 中的flock等待锁的时候在做什么呢？是在循环检查锁是否已释放吗？

解答：

1. 将等待锁的进程置为阻塞状态

2. 当锁被释放时，再把等待锁的进程唤醒，等待锁的进程都在文件的结构中已链表的形式排队呢

3. 当进程意外死亡时，内核会自动释放其获得的锁资源

参考资料：
Linux 2.6 中的文件锁：http://www.ibm.com/developerworks/cn/linux/l-cn-filelock/index.html

摘录：

表 3. file_lock 数据结构的字段

一个 file_lock 结构就是一把“锁”，结构中的 fl_file 就指向目标文件的 file 结构，而 fl_start 和 fl_end 则确定了该文件要加锁的一个区域。当进程发出系统调用来请求对某个文件加排他锁时，如果这个文件上已经加上了共享锁，那么排他锁请求不能被立即满足，这个进程必须先要被阻塞。这样，这个进程就被放进了等待队列，file_lock 结构中的 fl_wait 字段就指向这个等待队列。指向磁盘上相同文件的所有 file_lock 结构会被链接成一个单链表 file_lock_list，索引节点结构中的 i_flock 字段会指向该单链表结构的首元素，fl_next 用于指向该链表中的下一个元素；当前系统中所有被请求，但是未被允许的锁被串成一个链表：blocked_list。fl_link 字段指向这两个列表其中一个。对于被阻塞列表（blocked_list）上的每一个锁结构来说，fl_next 字段指向与该锁产生冲突的当前正在使用的锁。所有在等待同一个锁的那些锁会被链接起来，这就需要用到字段 fl_block，新来的等待者会被加入到等待列表的尾部。