Step1帐户登录系统(9. 总结和源码下载)
因为本次闭关期间还有很多任务没有完成，时间已经安排不过来，因此，只能比原计划提前结束此系列文章的介绍，不过反正需要介绍的内容差不多都已经介绍完毕了，只是提前进行源码的整理而已。
因为这是一个总结的贴子，因此，先列出之前的9篇文章内容：
Step1帐户登录系统(3.使用Google的Auth Sub登录网站)
Step1帐户登录系统(4.使用Windows Live ID登录网站)
Step1帐户登录系统(5.使用Yahoo BBAuth登录网站)
Step1帐户登录系统(7.使用OpenSocial接口登录支持校内网用户的登录)
Step1帐户登录系统(8. Step1.AccountClient的实现)
在本文的最下方，将会包含整个源码，而在此之前，我简单的说明一下一些心得和需要注意的地方：
1.关于此系统的安全问题，要知道，本系统由最终用户、Web应用（AccountClient）、AccountServer，帐户服务器四个角色组成，每一个角色都需要考虑自己角色的安全问题，大体如下：
a.用户对安全的考虑很直观，就是不希望在不信任的网站上输入自己的账户和密码，同时希望仅仅将用户自己授权的资料提供给Web应用网站，这个功能在本系统之中是满足要求的，实际上，这也是本系统设计的核心原理；
b.Web应用对安全的考虑最重要的是不受伪装的AccountServer的欺骗，要知道，AccountClient通过接收URL参数来得到用户信息并保存为Cookie，假如有一个伪装的URL参数，实际上是可以欺骗Web应用的，在我提供的源码以及目前线上的系统之中，并没有对AccountServer和AccountClient之间的交互进行加密处理，这是因为这只是一个研究性的项目，当我确实需要在此登录系统上开发安全级别高的应用的时候，一定会考虑加上安全的限制，可以参照AccountServer的帐户服务器的方法，为每一个Web应用分配一个秘钥，例如对双方传递的URL参数进行MD5的校验；
c.AccountServer的安全性有两个方面，一方面避免受到伪装的AccountClient的欺骗，实际上这种欺骗影响很小，通过b里面提到的md5校验的方式可以防止这种欺骗，另一个方面是避免受到伪装的帐户服务器的欺骗，这一点和各个帐户服务类型相关，例如Google的AuthSub，实际上AccountServer和AuthSub服务器之间的交互没有任何秘钥，很可能会被伪装，可能因为这种伪装对Google的AuthSub服务器没有影响，只是影响使用AuthSub服务端的程序，所以Google也不是很在意；同样，我实现的校内网使用的OpenSocial的模式，也没有在回转请求上加上密钥，而且以这种OpenSocial APP的模式来看，也很难能够加上什么很保险的密钥了；
d.至于各个帐户服务器的安全，则是帐户服务器提供方需要考虑的事情，因此，不在本文讨论之列；
2.大家可能注意到，每一种帐户类型，尤其是Google的AuthSub，Yahoo的BBAuth，Live ID,我除了完成用户的登录过程之外，还特别的费尽心机去获取用户的E-mail地址，Google帐户和Live帐户我采用读取地址本的方法，Yahoo的账户我采用读取Ymail发件人地址的方法，这些方法都需要去额外的向用户申请信息访问权限，我为什么一定要获得用户的E-mail地址呢？实际上这些帐户服务本身就会提供一个独一无二的ID的，为什么不直接使用这些ID作为用户的帐号呢？因为我不能信任帐户服务器提供的ID，以Yahoo的BBAuth为例，我发现我有一次重新申请了一次新的BBAuth应用之后，发现居然每个登录用户的ID也都跟着变化了，虽然对于每一个应用，登录用户的ID还是唯一的，不过谁也不能保证不会出现需要更换域名、重新添加权限等需要重新申请应用的时候，假如重新申请权限造成每个用户的资料丢失，问题就大了，因此，帐户服务器提供的号称唯一的ID是不可信的，还是获取用户的登录帐号比较可靠。
3.用户可能存在多种不同的账户类型，当用户以不同的帐户类型登录到系统的时候，系统肯定会认为是不同的账户；而且，Web应用判断用户是不是同一个，除了要判断用户的ID之外，还要加上帐户类型，因为不同的网站的同一个账户的类型肯定不能认为是同一个用户；
下面是本系统的两套源码：分别是AccountClient和AccountServer的源码：
这次系列的结束只是代表第一阶段的研究完成，我后面还会继续优化此系统，并且会继续发文探讨，不过暂时不会这么密集的发表了。
posted on 2008-12-07 12:59 K_Reverter 阅读(2544) 评论(5) 编辑 收藏 举报
