正在做一个企业内部单点登录平台，也就是 idaas
本来以为后端 api 给我获取到的 token 等授权信息
前端自己存起来就可以了
但后端这次方案使用了 Response 带 cookie ，前端调用 api 后直接作为只读 cookie 存在了前端
然后产生了 302 跳转登录页
我之前没这么做过，想咨询各位彦祖，哪种方案算是最佳实践
前端为 react 单页应用
后端应该是 springboot
多谢
本来以为后端 api 给我获取到的 token 等授权信息
前端自己存起来就可以了
但后端这次方案使用了 Response 带 cookie ，前端调用 api 后直接作为只读 cookie 存在了前端
然后产生了 302 跳转登录页
我之前没这么做过，想咨询各位彦祖，哪种方案算是最佳实践
前端为 react 单页应用
后端应该是 springboot
多谢
 |
1
c3de3f21 1 天前
如果是携带 cookie 不用前端做事的情况下
抓一个时间点，初次访问页面时尝试请求 user ，请求到 user 继续下面的流程 请求不到 user 和后端协商，是你跳登录还是后端跳登录 登录时候肯定携带了你的页面 url 走的，登录完了跳回来还是走 /user 请求 然后正常流程设置系统信息，用户信息菜单权限等等 |
 |
3
Oktfolio 1 天前
对于不同类型的应用实现不同的逻辑，如果是 SPA 就接口 401 的时候前端跳转，如果是传统网页就后端跳转。当然，也不一定要根据类型，反正做成可配置的就好。
|
|
4
Oktfolio 1 天前
SPA 做前端跳转，是因为前端跳转可以带上自己需要的参数，这样登录后就可以根据参数跳转回之前的页面了
|
 |
5
LittleFox 1 天前
如果前后端同源的话会自动处理 cookie 吧？不同源可能需要手动处理一下，感觉前后端不同源还是用 token 或者 jwt 舒服一点
|
 |
7
cus 1 天前 via iPhone
oauth2 bff 方案咯，公开的 client 被 SPA 用现在也被视为有风险的。没有不同源场景，逻辑是你不和 idaas 一个源，你和 bff 才是一个源。https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps
|
 |
8
mmmNover 1 天前
cookie 把，operas/cas 项目的标准方案
|
 |
13
meshell 16 小时 4 分钟前
@wangyzj oauth2 不需要考虑同源这种，我们的系统都是 oauth2 的单点登录，前端也是 spa 。我们是采用后端控制的跳转加 cookie 的，spring 原生支持这套体系。
|
 |
14
skallz 14 小时 36 分钟前
除了久远之前的系统，好像现在都不会第一时间考虑 cookie 了，很多平台对 cookie 还会做限制，到时候如果需要接入某个对 cookie 限制的平台还得重构，更何况 cookie 在现在除了自动携带也没任何好处了 QAQ （一般都是只拿 cookie 做中间存储跨站点传值而已）
|
Select Language