个人认为还需要优化的以下几点，不知是否合理？1：客户端登陆后应把自己的注销地址发到sso center2：客户端应本地缓存session，且时间不超过sso center返回的有效时间；客户端自行检查本地session, 过期后再次跳到sso center进行认证3：sso center接收注销请求后，主动调用客户端注销地址
epggiuax1#
你确定你的这种实现方式在分布式环境下可用？客户端本地缓存session，这个session你需要共享吗？注销操作你的意思是在center注销后通知每个子系统去调用自己的注销地址以删除客户端本地的session，你的思路是这样的吧！
cigdeys32#
1：客户端本地缓存session来源于sso center的，sso center肯定是有一份，也就是需要共享2：sso center接收注销请求后，主动调用客户端注销地址就是由sso_server调用接入系统的注销接口@younk-zhao
5lwkijsr3#
我也觉得客户端直连redis有点问题，感觉应该通过sso-server来远程访问比较好，楼主有什么好的建议，我正要需要这个sso，打算直接搬下来这一套
dba5bblo4#
如下内容，Copy From：#23
你好。如题，为什么客户端还要配置redis呢？我认为这应该是server端实现的细节。不同的设计方式吧，整个项目中，client端的redis现仅用于SSO_USER的获取并在请求中传递，个人觉得实现上有三种思路可考虑（个人看源码的见解，如有不对，请指正，谢谢）：1、server和client用相同的介质(例如现有的redis)存储用户及权限信息，这种情况的话，server端后续不仅做用户登录信息校验，同时做各系统资源权限配置2、server和client用相同的介质(例如现有的redis)仅存储用户信息，这种情况，权限交由各client端去配置实现3、server和client约定并配置登录成功后生成的sessionId和用户标识（如手机号）的加解密方式，这样server端就仅做登录校验并返回生成的用户标识sessionId信息，其它的就完全交由client端去实现了，这样client和server就没有什么组件耦合关系
63lcw9qa5#
如下内容，Copy From：#31
希望作者重新考虑下，功能上说支持跨域，也就是说支持2个业务站点互相访问，根据cookie或者token获取用户信息这块，client居然直接去连sso-server的redis，很多情况下是不现实的，这些场景下也直接导致该方案不可用，已经有兄弟建议使用http的方式访问sso-server验证cookie/token并拿到认证主体，然后在本地应用构建session。
看了下源码，其实实现是回调url通过参数传sessionid，然后再写cookie，这里设置cookie的domain为null来实现“大规模”跨域，不但跨域，而且跨了所有域，也就是所有网站都能拿到你这个cookie，基本没有任何安全性可言····
弱弱提几点建议：1、cookie的方式实现安全跨域确实比较麻烦，因为cookie天生不能跨域，所以有很多hack方法都需要在页面用js实现，比如使用ajax jsonp或者h5的iframe嵌套postMessage实现，不过这些可能都不是太通用的方案2、token天生支持跨域，如jwt这类携带信息多还轻量级的token可以考虑支持
r8uurelv6#
如下内容，Copy From：#30
感觉客户端项目最好还是不要连接sso-server的redis，如果能吧票据的校验换成http请求来请求sso-server而不是直接通过redis来查询会不会更好呢？这样客户端和sso-server的耦合度也低了很多
dba5bblo7#
请问该问题作者有好的思路了吗？
7条答案
按热度按时间epggiuax1#
你确定你的这种实现方式在分布式环境下可用？客户端本地缓存session，这个session你需要共享吗？注销操作你的意思是在center注销后通知每个子系统去调用自己的注销地址以删除客户端本地的session，你的思路是这样的吧！
cigdeys32#
1：客户端本地缓存session来源于sso center的，sso center肯定是有一份，也就是需要共享
2：sso center接收注销请求后，主动调用客户端注销地址就是由sso_server调用接入系统的注销接口
@younk-zhao
5lwkijsr3#
我也觉得客户端直连redis有点问题，感觉应该通过sso-server来远程访问比较好，楼主有什么好的建议，我正要需要这个sso，打算直接搬下来这一套
dba5bblo4#
如下内容，Copy From：#23
你好。如题，为什么客户端还要配置redis呢？我认为这应该是server端实现的细节。
不同的设计方式吧，整个项目中，client端的redis现仅用于SSO_USER的获取并在请求中传递，个人觉得实现上有三种思路可考虑（个人看源码的见解，如有不对，请指正，谢谢）：
1、server和client用相同的介质(例如现有的redis)存储用户及权限信息，这种情况的话，server端后续不仅做用户登录信息校验，同时做各系统资源权限配置
2、server和client用相同的介质(例如现有的redis)仅存储用户信息，这种情况，权限交由各client端去配置实现
3、server和client约定并配置登录成功后生成的sessionId和用户标识（如手机号）的加解密方式，这样server端就仅做登录校验并返回生成的用户标识sessionId信息，其它的就完全交由client端去实现了，这样client和server就没有什么组件耦合关系
63lcw9qa5#
如下内容，Copy From：#31
希望作者重新考虑下，功能上说支持跨域，也就是说支持2个业务站点互相访问，根据cookie或者token获取用户信息这块，client居然直接去连sso-server的redis，很多情况下是不现实的，这些场景下也直接导致该方案不可用，已经有兄弟建议使用http的方式访问sso-server验证cookie/token并拿到认证主体，然后在本地应用构建session。
看了下源码，其实实现是回调url通过参数传sessionid，然后再写cookie，这里设置cookie的domain为null来实现“大规模”跨域，不但跨域，而且跨了所有域，也就是所有网站都能拿到你这个cookie，基本没有任何安全性可言····
弱弱提几点建议：
1、cookie的方式实现安全跨域确实比较麻烦，因为cookie天生不能跨域，所以有很多hack方法都需要在页面用js实现，比如使用ajax jsonp或者h5的iframe嵌套postMessage实现，不过这些可能都不是太通用的方案
2、token天生支持跨域，如jwt这类携带信息多还轻量级的token可以考虑支持
r8uurelv6#
如下内容，Copy From：#30
感觉客户端项目最好还是不要连接sso-server的redis，如果能吧票据的校验换成http请求来请求sso-server而不是直接通过redis来查询会不会更好呢？这样客户端和sso-server的耦合度也低了很多
dba5bblo7#
请问该问题作者有好的思路了吗？