这里，为了更好的说明情况，引入一个场景 。
首先说下非跨域的身份验证，在我国古代，皇上的江山，肯定是由皇上说了算，谁能做什么，谁不能做什么，可是皇上也不能天天自己检查，于是，发明了令牌，见到令牌着，就犹如见到了皇上，那这个令牌，就是我们需要验证的钥匙，如果这个令牌是真的，那么好说，如果令牌无效或者是伪造的，当然没有办法做你想做的事情，皇上发了令牌，但是也不能自己来发自己查，于是，建立一个令牌发放以及验证的一个衙门，专门负责发放令牌，以及验证令牌真假。于是，在我们自己的国度内，一个身份验证的问题解决了，一旦一个人有了令牌，把令牌别在腰里，遇到需要用的时候，出示一下，然后门卫拿着令牌到验证部门验证一下，回来说，没问题，可以进行操作了。
以上的场景，令牌，就是我们在站点中登录成功后保存在客户端的加密串，所谓把令牌别在腰里，就是用一个cookie来存储这个加密串，发放以及验证令牌的衙门就是服务器端的身份验证模块，无论何时需要验证身份，从cookie中取出加密串，发给身份验证模块，验证模块校验后返回结果，然后其他模块允许或者拒绝操作。如果令牌不在腰上或者丢了怎么办？通过用户名和密码，再到身份验证模块处要一个回来，付出的成本就是在登录窗口填写表单，然后提交。
下一个场景，默认cookie是只在一个完整域名下使用 ，比如aaa.site.com 和bbb.site.com 是不能共享的，这个好办，毕竟都是在同一个国度，只是不同的省份而已，都在皇子脚下，让验证部门允许跨省使用即可，设置cookie的 domain 为site.com，这就很容易的实现了同域下，不同二级域的cookie共享。
但是我们这么大的一个国度，没有几个友好邻邦是不行的，而且还要经常派一些大使相互往来。这就涉及到了跨站点，跨域访问身份的问题了。一随便什么人，跑到高丽，想吃吃，想喝喝，谁能知道是真的还是假的。
于是，两国协商，拿着我国令牌的人，就是大使，能够正常在你国行动。协议达成，然后我国派一大使，就想要直接进入高丽国宫殿，这时，高丽国的门卫肯定还不认识你啊。当然不能让你进去，把你赶到登陆注册处，这时，你发现腰间的令牌不在了，为虾米？哦。令牌只在本国的时候才能挂在腰间，无法带出来啊。安检不让带。那咋办呢？还好，咱们带的有随从（javascript），这个随从呢，可是来自宫中的，他自当回到令牌放出，找到令牌，然后带回到登陆注册处，不用填写任何密码还有用户名了，直接把这个令牌递交给高丽国验证处，这里如何给呢？当然可以通过URL传值或者hidden表单的方式，只要高丽国拿到了这个令牌，那就简单很多啦，毕竟两国交往，高层办事很容易，发送一个webservice，传递这个令牌给国内，国内一看，没问题，返回可以使用，就这样大使通过验证后，就大摇大摆的该吃吃，该喝喝了，但是这个令牌不能丢啊，更不能总让随从保管着，于是在高丽国新买一个口袋（域为gaolisite.com）来存放这个令牌。这样再需要使用的时候，就不需要随从回国找令牌去了。
解释：随从为什么可以从国内拿到令牌？因为随从来自 site.com/suicong.aspx (并非简单的静态js) ，这样，这个动态生成的js就能在服务器端获取到保存在site.com下的验证令牌。然后保存到变量，加载到中或者直接构造成URL，提交给高丽验证处，即可，这些操作可以由程序自动实现。
另外令牌一定要加密，否则被人随便仿冒一个，这里就要有安全漏洞了。加密后的令牌还需要能够解密，这样，才能找回身份信息。
示例代码： 跨站点身份验证示例
示例代码说明：
将WebSite3 配置在IIS中，可以通过IP访问或者127.0.1访问
WebSite2 为集中验证服务器, 可以直接使用VS.net打开，访问路径为 http://localhost:57506/WebSite2/Default.aspx
如果访问路径不一样，需要找到相关的代码，使httprequest可以访问。
首先在没有登录的情况下：访问另个站点的default.aspx页，会在site2中显示登录窗口，site3中显示没有登录，
然后在site2中登录，刷新site3，可以看到site3已经实现自动登录，然后在site3中退出，site2也自动退出。
另外，自动退出的功能还不完善，如果在site2中退出，site3是没有退出的，修改办法是清除所有站点登录令牌cookie。
最新评论