作者:路人甲 | 2021-09-08 09:33
回复内容:你给我私信里说域名不是简单父子域名的关系,所以直接的cookie共享是不可行的。提供一种比较好做的方案,假设你有三个不同域名,a.com,b.com,http://c.com,将其中之一作为真正的登陆入口,所有的域名下发起的登陆,全部重定向到这个节点,这里假设选择http://a.com/
回复内容:
你给我私信里说域名不是简单父子域名的关系,所以直接的cookie共享是不可行的。提供一种比较好做的方案,假设你有三个不同域名,a.com, b.com,
http://c.com,将其中之一作为真正的登陆入口,所有的域名下发起的登陆,全部重定向到这个节点,这里假设选择
http://a.com/login.php为统一登入节点,为了方便说明,把
http://a.com叫做主节点,其余叫做从节点。
假设现在从任意站点发出登陆请求,最终都被带到
http://a.com/login.php?from=b.com&sfkey=xxxxxx,用户输入登陆信息,假设登陆成功,返回一个登陆成功中间页面,在这个页面里,包含下面html代码
途牛最牛逼的首席架构师兼途牛董事会成员 @曹河图的博客
一个单点登录系统设计
如果你的要求不高 ucenter是一种解决方案
说一个不同的答案吧——广播机制。同样,以
http://a.com作为主域名,不论
http://b.com还是
http://c.com登录时请求都提交到
http://a.com,所有的存储都在
http://a.com,其他域名不允许访问。在
http://a.com登录成功后,将登录信息存放在
http://a.com域下的cookie中。此时发起广播,由client端通知
http://b.com和
http://c.com,说用户已经登录(仅仅是告诉他们已经登录),此时用户访问
http://b.com或者
http://c.com时有server端向
http://a.com请求获取用户信息,并将非敏感信息存储到自己的存储当中。同理,登出时也是向
http://a.com发起登出请求,
http://a.com将用户cookie清掉,
http://b.com和
http://c.com再次向
http://a.com请求验证用户身份时,则验证失败。
没有楼上那些说的那么复杂。
一般两种方案:
1 共享SESSION(db,nosql等)
2 通过接口对每个域名下写cookie(常见ucenter)。
至于那些在页面上做处理,不现实的。一则涉及面广,二则维护不方便,也不符合业务封装(模块化)的架构思维。
如果不考虑异地部署话,可以将用户登录信息统一存在服务端的共享存储里,memcache或者redis都是可以的;当用户由
http://a.com跳转到
http://b.com之前在url中生成一个加密串,加密串中存放相应的登录信息key及校验信息。用户跳转到
http://b.com后解密url中的参数并去共享存储中获取用户登录信息。当然,如果需要相对安全一些,可以对用户在
http://a.com时的sid、ip之类的信息进行验证,同时控制url中登录参数的生命周期。验证通过后再在
http://b.com的服务器上写入本地登录信息。退出的时候注销掉共享存储中的登录信息即可。
上述url中的登录参数作用类似于cas这类sso解决方案中的ticket。
不错!
最后的结果呢?
占坑… 等自己博客更新后来埋答案