siganushka 最近的时间轴更新 siganushka 最近的时间轴更新 | siganushkaV2EX 第 379025 号会员，加入于 2019-01-21 19:37:12 +08:00 |
github.com/siganushka
| 出自用 Thinkpad x1 Gen9（2021）港版 二手交易 siganushka 2024-09-05 11:28:18 AM 最后回复来自 siganushka | 9 |
| 西安出一台戴尔 U2412M 显示器 二手交易 siganushka 2021-10-09 10:46:04 AM 最后回复来自 siganushka | 5 |
siganushka 最近回复了
2022-05-05 14:32:51 +08:00 回复了 rightcapital 创建的主题 酷工作 [北京][外企][965] RightCapital PHP / React 开发招聘 |
有远程岗位吗？感觉我还挺匹配的，我还曾为 Symfony 和 PHPStan 提交过代码（已 merged ），我的 Github： https://github.com/siganushka
2020-09-21 13:31:31 +08:00 回复了 cydian 创建的主题 问与答 「需求明确」推荐笔记本，预算 1W-1W5，有中意的 50 元红包，谢谢 V2er |
XPS 9300 比较合适，但价格坑爹
2020-09-02 11:46:05 +08:00 回复了 mitu9527 创建的主题 程序员 关于前后端分离中的 Session 和 Token ，请教大家几个问题。 |
“会话”只是一个抽象概念，不管是传统的服务端 session，还是 API 里的 JWT，本质都是把两次本不相干的链接关联起来，session 里的 session_id 和 jwt 中的 token 都需要服务端管理和维护，由客户端负责存储，两次链接发送的值一样，即可认为是同一个会话。
像 JWT 一样，服务端的 session 也可以自定义 session_id 和存储逻辑，因此本质上我认为他们是同一个抽象对于不同场景的不同实现，其直接有细微差别，比方说如果你把 session_id 在 cookie 中的 key 改成 token，值为 JWT 的 token 值行不行？然后自己实现存储逻辑，这不和传统的服务端 session 一样么？
之所以你觉得不一样，可能是因为他们的场景有细微的差别，1 是浏览器对于 cookie 的支持相对于 APP （或各种客户端）更好，因此默认不需要客户端手动操作，服务端就能实现整个 session 实现。2 是对于 JWT 的定义中，一旦服务端颁发 token 给客户端，在过期之前服务端无法撤销。
如果让你自己实现一个类似服务端的 session 功能，你想想你该怎么做？想到最后可能就是另一个 JWT ！
像 JWT 一样，服务端的 session 也可以自定义 session_id 和存储逻辑，因此本质上我认为他们是同一个抽象对于不同场景的不同实现，其直接有细微差别，比方说如果你把 session_id 在 cookie 中的 key 改成 token，值为 JWT 的 token 值行不行？然后自己实现存储逻辑，这不和传统的服务端 session 一样么？
之所以你觉得不一样，可能是因为他们的场景有细微的差别，1 是浏览器对于 cookie 的支持相对于 APP （或各种客户端）更好，因此默认不需要客户端手动操作，服务端就能实现整个 session 实现。2 是对于 JWT 的定义中，一旦服务端颁发 token 给客户端，在过期之前服务端无法撤销。
如果让你自己实现一个类似服务端的 session 功能，你想想你该怎么做？想到最后可能就是另一个 JWT ！
Select Language