话说passport的整合

话说passport的整合

如果是几套全新的系统，passport可以深入嵌入到系统中，虽然做的事情需要多点，能讨论的东西却少一些。

假设有3个域名 a.com ,b.com,c.com
passport位于c.com.

一、如果在a.com访问后，登陆，然后再访问b.com,如何保证这个时候b.com是登陆状态？
passport总的意思就是要在一个点上面记录下一个key,然后用这个key到其他站点中去执行相应操作。那么通过地址栏url参数转发，或者cookie操作总有办法把passport的状态传递到b.com的。如果用url参数转发，那就是一直跳转来又跳转去，比较傻冒。跳那么一天还不累死啊！而用cookie，在firefox下部存在跨域问题，而在ie下，默认隐私策略是不允许跨域操作哪怕是读取cookie的。当然cookie问题可以用p3p解决，这样javascript + p3p就变成了很友好的解决方案。像sohu就是这么做的。

相应的，在a.com退出，同时删除passport的状态，那么b.com也就有办法退出了。至于passport的状态只是简单得存储为cookie还是保持到比如数据库中，各有各的好处。只保存cookie，那么相应的处理简单点，而跨域操作cookie需要一个代理，所以这种情况下操作时在客户端判断状态再执行操作。而把登陆状态存储到数据库则可以在服务端进行操作，弊端是可能会有极大的开销。

二、我已经有了3个系统，现在做了个passport，怎么整进去才好？
最好的整合肯定是深层次整合，3套系统都用一套用户方案。但是，要是3个系统都有登陆，虽然用的同一套用户数据，但是要把3套用户验证方案整合成一个还是有很大工作量的。

如果只是需要验证，或者分步骤进行的话，那么只把登陆分离出去，然后在登录的时候把状态写入passport就可以解决问题。一旦passport有了状态，然后在本域进行强行验证就可以了。甚至可以不用在在passport下放统一登陆窗口，可以沿用自己原先的登陆窗口，只是额外加一段代码，把登陆完的状态copy到passport上。当然，不在passport下登陆，复杂度会加强一些。

凌驾于其他登陆方案上面再放一套用户验证无疑是最精简的办法。不但改造成本小，即使万一passport出了问题也不会影响其他各自系统的使用。