推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
前后端分离，用 React/Vue 框架下，用户权限应该用 cookie 验证？还是 token 验证？
liudaqi · 2020-12-21 14:20:21 +08:00 · 5205 次点击这是一个创建于 1434 天前的主题，其中的信息可能已经有所发展或是发生改变。
前后端分离的框架，用户权限大家用 cookie 验证？还是 token 验证？
 |
1
tabris17 2020-12-21 14:22:48 +08:00
都一样，cookie 本质上也就是 HTTP 请求的一个头部而已
|
 |
2
3dwelcome 2020-12-21 14:27:04 +08:00
传统的 Cookie 挺好用的，然而我另辟蹊径，用的是 localStorage 存用户的 session 。
是为了兼容一些特殊的场景，我代码里面很多服务器推送，WSS 之类的，没发 HTTP 请求，也就没实时更新 cookie. |
 |
3
u6pM63mMZ34z32cE 2020-12-21 15:23:54 +08:00
token
|
 |
4
ben1024 2020-12-21 15:27:30 +08:00
有中间层就 cookie + csrf
没有就 token |
 |
5
hanxiV2EX 2020-12-21 15:28:34 +08:00 via Android
同时上
|
 |
6
totoro52 2020-12-21 15:38:03 +08:00
看你后端喽
|
 |
7
sunderls 2020-12-21 15:42:13 +08:00 via iPhone
Cookie 是 client 存储技术
token 是数据签名 二者不存在二选一的问题 你想问的估计是用 token 还是用 db 维持 session 这个取决于服务器端的设计 考虑到多台服务器的共享问题。token 的扩展性更好 至于 client 的存储 因为 cookie 有 httpOnly 选项 比其他 localstorage 之类的更好 所以一般情况下。建议 cookie （ httponly ） + token |
 |
8
VensonEEE 2020-12-21 15:51:36 +08:00
这和 vue 、react 没有关系。
复杂的系统，分布式的系统，token 是首选。拓展性强。 简单的系统，基于 session 的认证，cookie 是首选。简单易维护。 |
 |
9
securityCoding 2020-12-21 15:55:49 +08:00
写来写去最后都会变成 token , 存哪里不重要最终都要被服务端获取并解析
|
 |
10
duduaba 2020-12-21 16:10:59 +08:00
具体问题具体分析啊。如果只是自有业务那 cookie 、token 都可以，如果是对接第三方，比如要 iframe 嵌入到其他系统，在二级域名保证不了同一源的情况下只能用 token 这种方式。所以如果考虑更好的扩展性，建议用 token 。
|
 |
11
CoderGeek 2020-12-21 16:19:01 +08:00
token
|
 |
12
chendy 2020-12-21 16:25:12 +08:00
用 cookie 其实也是把 token 存在 cookie 里
项目简单的话这种方式也够用了 |
 |
13
ysicing 2020-12-21 16:28:28 +08:00
看场景咯，我们是有 cookie 先用 cookie，没有在查 token 🌹🐔
|
 |
14
rodrick 2020-12-21 16:30:33 +08:00
应该是想要问 token 存 cookie 还是存 webStorage ？还是问直接用 cookie 存鉴权信息？
|
 |
15
Sapp 2020-12-21 16:32:28 +08:00
这对前端不是一回事吗？你用 cookie 还不是等于把 token 存进去？你用 token 你自己存进 localStorage 里不也是 cookie 的效果？只是要手动添加进 headers 里，cookie 他会自己带进去而已
|
 |
16
shanghai1943 2020-12-21 16:33:08 +08:00
@3dwelcome #2 老哥请教一个 websocket 负载均衡的问题。之前用 ws+nginx+java 的 spring 架构，在 NGINX 端采用了 ip_hash 的方式来做负载均衡，弊端是每个 ws 连接只能固定请求到某个后端服务，如果该服务重启了就可能导致 ws 的连接全都失效了，相当于重新指向别的后端服务了。想请教下你们是如何处理 ws 的负载均衡问题的？感谢。
|
|
17
3dwelcome 2020-12-21 16:46:09 +08:00
@shanghai1943 我们的服务器都是热加载更新的，只要机房不掉电，用户 ws 就不会断线，完全不存在你说的这种情况。
|
|
18
shanghai1943 2020-12-21 16:48:51 +08:00
@3dwelcome #17 方便透露你们的服务器是用的什么架构技术么？感谢。
|
|
19
3dwelcome 2020-12-21 17:07:00 +08:00
@shanghai1943 我们的 ws 模块是插件化接入到 web 服务器，所以热加载比较容易。
你们 nginx 热加载应该也是可以的，可能后端没吃透这块。 为了用户体验考虑，强行踢下线感觉肯定不好。如果后端实在太菜，你们前端可以加个状态恢复功能，在无感知情况下让用户重连。（正常 websocket 断开和踢用户下线走两个不同的初始化路由） |
|
20
shanghai1943 2020-12-21 17:14:36 +08:00
@3dwelcome #19 我们这边用的是 NGINX 做了请求的负载均衡，你们那边是用什么来做负载均衡的？
|
|
21
3dwelcome 2020-12-21 17:19:09 +08:00
@shanghai1943
我们用户数还没到负载那部分。。可能给不了什么有效建议，一台服务器正常也能撑个几万连接数了。 我可能没看仔细你的问题，热加载对于跨不同服务器，好像是没什么特别的帮助，socket 都断开了。 这种案例，以前网游服务器集群挺多的，可以考虑参考一下。 |
|
22
shanghai1943 2020-12-21 17:22:52 +08:00
@3dwelcome #21 好的。感谢。
|
 |
23
karnaugh 2020-12-21 17:24:06 +08:00
如果跨域名的话，就只能 cookie 咯
|
 |
24
bianz103 2020-12-21 18:11:45 +08:00 via iPhone
可以 cookie 和 token 都支持下。小程序没有 cookie
|
 |
25
KuroNekoFan 2020-12-21 18:38:24 +08:00 via iPhone
我觉得当代 web 开发能避免 cookie 就避免 cookie
|
|
26
KuroNekoFan 2020-12-21 18:39:22 +08:00 via iPhone
不过你这问题问的不明确，token 也可以以 cookie 的形式存在啊
|
 |
27
darknoll 2020-12-21 18:52:56 +08:00
cookie 方便呗，但是没法跨域
|
 |
28
amundsen 2020-12-21 18:53:51 +08:00
jwt 的设计就行了。
|
 |
29
crclz 2020-12-21 19:51:05 +08:00
后端支持 2 种呗，既满足了习惯于用 token 的，又满足传统的
|
 |
30
xuanbg 2020-12-21 20:13:01 +08:00
cookie 只是浏览器存储数据的一种方式，和 token 不是一回事啊。和 token 对标的是 session 。session 和 token 本质上没啥差别，只不过 token 可以承载更多的信息，使用上更加灵活。
|
 |
31
learningman 2020-12-21 20:15:28 +08:00
@3dwelcome 那更推荐 sessionStorage，和 cookie 的 httponly 差不多
|
 |
32
chairuosen 2020-12-21 21:33:48 +08:00
token 。 想深一点，根本区别是后端控制流程，还是前端控制的问题。 前后不分离时期是后端控制，前后分离是前端控制。
|
 |
33
weixiangzhe 2020-12-21 22:24:48 +08:00
后端只有 jwt 和 session，前台存的 sessionid 或者 token 个人认为能用 httponly 的 cookie 直接用 cookie 就好，不行就会 sessionStorage 吧
|
Select Language