许雪里

如下内容，Copy From：https://github.com/xuxueli/xxl-sso/issues/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就没有什么组件耦合关系

如下内容，Copy From：https://github.com/xuxueli/xxl-sso/issues/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可以考虑支持

如下内容，Copy From：https://github.com/xuxueli/xxl-sso/issues/30 感觉客户端项目最好还是不要连接sso-server的redis，如果能吧票据的校验换成http请求来请求sso-server而不是直接通过redis来查询会不会更好呢？这样客户端和sso-server的耦合度也低了很多

如下Copy From：https://github.com/xuxueli/xxl-sso/issues/29 貌似有一个12小时后刷新redis的bug SsoTokenLoginHelper.java 的第74行： // After the expiration time has passed half, Auto refresh if ((System.currentTimeMillis() - xxlUser.getExpireFreshTime()) > xxlUser.getExpireMinite()/2) { xxlUser.setExpireFreshTime(System.currentTimeMillis()); SsoLoginStore.put(storeKey, xxlUser); } 不能用毫秒与分钟进行比较。。。

你好，感谢反馈！ 预计在下个大版本将会提供官方 docker 镜像；

你好，感谢反馈！ 该问题已经加入TODO，将会排序处理。

你好，感谢反馈啊！ 1、响应参数建议用 “数据类型” 来配置，实现数据类型的复用。 2、请求参数支持拖动排序，这个加入TODO，将会排期迭代。

你好感谢关注！ 导出功能缺失很有必要，已经将该功能接入项目TODO LIST，将会按照优先级进行排期：）

你好，该需求添加至项目TODO中，将会排期跟进。

你好，该需求已经加入TODO，将会排期处理。