这是一个创建于 991 天前的主题，其中的信息可能已经有所发展或是发生改变。
在公司实习做过后台系统，用 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