这是一个创建于 1323 天前的主题，其中的信息可能已经有所发展或是发生改变。
在公司实习做过后台系统，用 SS 做认证+授权。最近毕设也想参考着做一个后台系统，另外再加一个客户端。
现在的问题是后台系统和客户端的用户表是分开的（ sys_user 和 client_user ），也想统一用 SS 鉴权。我看到公司用 SS 做的后台除了查用户表认证外，还联表查角色菜单进行授权，我打算毕设的后台系统逻辑也这么弄。但客户端比较简单，只需要认证 token 合法性就放行，不需要涉及角色菜单这些，这种情况我觉得用 SS 可能有点重，但非要用的话由于两个用户表互相独立，那就需要走不同的登录逻辑了。大佬们应该如何优雅地使用 SS 处理后台的认证+授权和客户端的认证呢？感激不尽!
现在的问题是后台系统和客户端的用户表是分开的（ sys_user 和 client_user ），也想统一用 SS 鉴权。我看到公司用 SS 做的后台除了查用户表认证外，还联表查角色菜单进行授权，我打算毕设的后台系统逻辑也这么弄。但客户端比较简单，只需要认证 token 合法性就放行，不需要涉及角色菜单这些，这种情况我觉得用 SS 可能有点重，但非要用的话由于两个用户表互相独立，那就需要走不同的登录逻辑了。大佬们应该如何优雅地使用 SS 处理后台的认证+授权和客户端的认证呢？感激不尽!
 | 1 putaozhenhaochi 2022-03-06 17:16:17 +08:00 via Android 太重不用。 自己写个过滤器。 |
 | 2 pelloz 2022-03-06 17:25:33 +08:00 不要用，等你看懂并且能够正确使用的时候，其他业务代码早就写完了。你自己先简单写个过滤器就行。 |
 | 3 bigbyto 2022-03-06 19:12:40 +08:00 via iPhone 看一下官方文档吧，写的非常详细了。spring security 的代码质量是 spring 家族中数一数二的高，花点心思会有很大收获。 |
 | 4 Terminator0826 OP @bigbyto 其实是想问我后台系统那边用了，客户端那边也用合适吗，客户端那边不像后台系统那种用法，仅仅只是拦截了校验一下 token 。客户端如果用应该怎么区分和后台系统那边的校验逻辑。目前网上也搜不到类似的做法，感觉可以用策略模式区分不同端的逻辑，但是感觉要写好多东西，还是说客户端就像前面老哥说的那样简单写个 filter 就可以了。 |
| 5 bigbyto 2022-03-06 19:54:06 +08:00 via iPhone @Terminator0826 简单验证确实直接用 filter 就可以了，没必要引入一个框架处理。 |
 | 6 leafre 2022-03-06 19:54:14 +08:00 需要鉴权的 url 资源使用标识区分开，如 api_admin/**/**，非管理端路径无需鉴权直接放行 说写个 filter 就能替代 spring security 的可能没被拖库过 |
| 7 Terminator0826 OP @leafre 我客户端的用户表和管理端的用户表是分开的，只是资源标识区分感觉还是不行，因为 SecurityConfig 里面目前配置都只是管理端的拦截逻辑，里面的各种 handler 也是查的管理端的表。总的来说，应该是 config 配置的各种 handler 还有 filter 要怎么优雅地区分才是我想知道的 |
 | 8 cppc 2022-03-06 21:08:00 +08:00  1 感觉你说的这个场景就是 spring security oauth 的应用场景，其中 client_user 对应 client authentication ，有很对开源项目可以借鉴，比如 https://github.com/pig-mesh/pig |
| 9 Terminator0826 OP @cppc 感谢，我一会研究一下 |
 | 10 damai0419 2022-03-06 22:14:54 +08:00 前台后台用一套校验逻辑比较好。 如果非要前台不涉及鉴权的话，可以前台请求头上搞个标志。后面 SS 判断标志，不进行鉴权。 |
| 11 damai0419 2022-03-06 22:20:42 +08:00 1 |
| 12 Terminator0826 OP @damai0419 好嘞，学习学习 |
Select Language