V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  zpf124  ›  全部回复第 4 页 / 共 69 页
回复总数  1374
1  2  3  4  5  6  7  8  9  10 ... 69  
@yangxiaopeipei 有成功的有失败的,因为前俩没扔进去的时候我没醒。
我完全放松的情况下是嘴微张的, 以至于曾经上课仰着头睡着后老师还试着往里扔粉笔...
@encro

我也和你说了, 许多人用 jwt 不是要解析校验里面的信息,他们也不会把 jwt 校验通过当作登录成功的判断标准,仅仅是拿 jwt 格式的 token 当 key 去 redis/mysql 里查相关信息,自己实现了一遍 session 管理。


楼主提到的内容也是 jwt 无法失效、也不应该用 jwt 做撤销功能而被而被二把刀嘲讽。
如果要实现撤销功能,那就是中心化的,就需要有会话管理查询的地方,那就是自己重新套着 jwt 的皮实现了一遍 session 管理。
那么就不可能 “不需要服务器存储 key 以及 data ,无需存储即意味几乎无成本分布式(除了 cpu 加解密运算和传输头信息) ”
@encro

然而你这部分理解还是有问题,
sessionid 并不一定非要 cookie 才可以,只是 cookie 默认就会携带无需前端做什么。

以 Java 语言的 tomcat 服务器为例,session 的字段叫 JSSESSIONID , 服务端首先会从 cookie 里尝试读取, 读取不到,会尝试从 header 里读取,还读不到会再从 url 参数中尝试读取, 都没有的情况下,才会认为这是一个新的会话,会生成一个新的 id 。

所以, 在不支持 cookie 的环境下,jwt 也得通过代码实现,从 localStorage 或者其它本地存储中读取并添加到,header 中,而 sessionid 自然也可以这么干。


jwt 的真正优势是, 服务器不需要存储会话信息, 不需要联机校验, 当 jwt 携带的 hash 与内容校验一致就可以认为是该用户,然后直接判断权限,操作数据即可,操作完了也不需要保存这个用户任何信息,下次新用户来了再重新做一次 jwt 校验就行。

然而许多蠢人盲目随大流或者有些人怀着练习新技术的想法, 使用 jwt 作为 session Id 又重新实现了一遍 session 管理,把 jwt 弄成了 session 的形状,等于是放着默认已经支持的 session 实现不用,自己手写代码实现了一遍。

在这种环境中,jwt 只是一个去 redis 或者 mysql 获取数据的 key , 检查 jwt 完整性屁用没有, 还得去查相关的库表,确认该 “token” 没有失效后,再加载这个 jwt 对应的在服务端保存的缓存数据(这个东西在原来的实现里 我们称之为 session )。

甚至有些后端还会在这一步给这个 jwt 客户端签发一个 sessionid ,这样下次这个 jwt 客户端就可以不用再走上面的校验流程了。
在给 jwt 套上一层 session 管理后, 又为某段时间内某个客户端添加了默认的 session 实现,对于这种夹心饼的嵌套做法,看的我实在是叹为观止。
@encro

不知道你的 frontend server, backend server 是什么东西, 反正和我的理解完全不一致,你真的经历过 session 时代吗?


我的认知里的前端服务器主要是用来做服务端预渲染,那么它实际作用和代理类似, 只转发请求和返回 backend 的数据就好了, 为什么要在这生成 sessionId ,并且我也没理解你这里生成的 session id 是怎么办到可以去 backend 通过鉴权的。


session id:
1 、登录 browser->frontend server(无 SSR 需求的可去掉)->backend server (实现登录并返回 sessionid )
2 、操作某数据 browser ( head 包含 session id )->frontend server ->backend server
3 、获取通用展示数据 browser ( head 包含 session id )->frontend server ->backend server
或 从登录后的写入的某自定义 cookie 中读取。

jwt:
1 、登录 browser->frontend server(无 SSR 需求的可去掉)->backend server (实现登录并返回 jwt )
2 、操作某数据 browser ( head 包含 token )-> frontend server ->backend server
3 、获取通用展示数据, 从 jwt 的 payload 中解析部分字段,不发送请求

我不理解你的思路,没明白你在做什么。

在我的描述的中
2 是用 session id 还是 jwt ,效果有什么不一样吗?替换使用有什么区别吗?
3 两者略有差异,但这差异大吗? 即便是无法使用 cookie 的场景,session id 的使用方式也只需要第一次多发一个获取通用信息的接口,然后和 session id 、jwt 存储到同一位置,以后使用一样是客户端本地读取。
@encro

你提到的前端框架里如何使用 jwt 只是流行程度高的一套最佳实践而已,只是现在更流行而已不代表只能如何或者这种方式什么场景都有优势。
vue,react 你如果想找也一定可以找到使用 sessionid 保持会话的方式,区别只是你用 jwt 时 是 jwt 这个字符串可以拆分出来一个 json ,里面可以解析到一部分用户信息,而使用 sessionid 时 可能会有 另外一个叫 userinfo 的 json 串保存这些通用数据给你们前端,或者干脆有 4 、5 个不同的 cookie 分别叫 username ,head_img ,当然用 localstorage 也一样。


然而 jwt 的 token 只能存放不敏感且通用的数据,比如用户名,昵称这种。 其它像某个子模块下的具体信息,还有敏感信息是不应该存在 jwt 里的, 比如某个子模块下的菜单顺序,手机号,身份证号,密码加密串,当你需要操作这些数据的时候,jwt 和 session 方式没有区别, 只是 jwt 是传的一个 特定格式的字符串,而 session 传的是某种服务端生成的随机字符串, 对于服务端来说 这都仅仅是一个 证明 “你是你” 的 ticket 。
针对楼主的疑问,遇到二把刀不论在什么行业都是常态,甚至我在某些领域也是二把刀,发表过错误的观点。

-----------------------------------
1.1 、jwt 原本指的是一种 服务端签发后不保存状态的用户凭据, 任意一个客户端偷到了这个 key 都可以代表他进行访问,服务端不特定存储某个 key 的针对性数据。
1.2 各类 session id 方案,指的是一种服务端记录客户状态,然后客户端只传递一个随机生成的 session id ,服务端根据这个 id 从 map 中找到对应的登录状态数据。

但现实情况是 流行的技术会随着它的拥趸将本来它不擅长的领域里的更合适的方案给挤掉,然后这些拥趸会为了让她更适应这个领域而改成个四不像。
所以现在有些项目配置文件也都非要用 json 替换了,然后替换了发现没法写注释、并且嵌套多了人眼没法看了,就又根据 json 发明了个 toml 。
觉得机械都是应该轮子移动的设计师们,设计走不平整路面甚至楼梯的机器也是安装的轱辘,觉得以前的机械腿太落后低效,都没人研究了,可轮子又确实不好用结果又给这个轱辘安装一个杠杆,整的像是腿和轮子的私生子。

jwt 也一样, 本来需要限制多端唯一、风险用户踢退等操作的系统,也由于开发者觉得 session 是落后的过时技术,要追随主流流行技术而采用了 jwt , 然后又为了实现这些与 jwt 思想背道而驰的需求, 发明了 失效校验服务,服务端将所有签发的 jwt 都存起来记录他们对应的失效信息,以及那些不同的 jwt 对应同一个用户。

这些人放弃了浏览器和服务端程序都支持了很多年的 cookie + sessionId 的 session 方式, 又自己手动实现了一遍 自定义的 通过 redis + mysql 的 session , 然后还美其名曰 jwt 的新用法。

------------------------------------
2.1 、二把刀们的错误认知,spa 、app 还是传统网页和用 session 还是 jwt 没关系。session 诞生于旧网页时代, 现在许多人所谓的 jwt 只是另一种没有使用 cookie 的 session 技术,app 发送请求的方式或者某些 webview 确实无法使用 cookie , 但传的 url 参数(或 header)参数名叫 jwt 还是 JSSESSIONID 没什么区别。
2.2 jwt 的 token 是有固定格式, 但 token 只是一个泛化的概念, 用服务器端的客户端连接序号 1 、2 、3 当 token ,还是用 md5(当前时间戳 + 用户信息) 都无所谓,甚至明文 也可以被称为 token 。
2.3 这样的人其实不少,不局限于前端,许多后端都一样,jwt 对于对于他们而言都只是一个标记, 和 sessionid ,md5 的用户 id 一样,不会想着往里面放不敏感的有用信息,更不会考虑解析内容,这使用一个 redis (或服务器内存中 map) 的 key 。
@encro 前后端分离和用 jwt 没有关系。
前后端分离了,除非展示前端的 webview 不支持 cookie ,否则 session 依然可用。
212 天前
回复了 fireworksV2 创建的主题 Java 使用 Docker 部署项目,编码注意事项有哪些?
@lsk569937453 早期 jre 无法识别 docker 容器资源 limit 限制,如果不指定 Xmx 之类的参数会直接按照宿主机内存大小进行分配,容易超限 oom , 后续不知道 java 10 几来着 在 openjdk 级别做了一些通用设置可以识别 jvm 可以支持识别 容器限制了。

java 8 按道理后面的版本可能也有加类似的功能,只是当时还是几个不同提供商自己私有实现,没统一规范。
@zypy333 戳到你痛点了?

我在谈如何处理实际问题,而不是站在道德制高点来句轻飘飘的 “不用治疗,用爱感化就好”。
@zypy333 我对所有抗拒治疗的精神病人都是一个印象, 敏感又脆弱,听不得别人说病、说治疗。觉得自己吃药治病了就是承认了自己是精神病,还不如不治遇上嘲笑的硬梗着脖子说自己没病。
@Cu635 我说别让她以为是送杨永信那了,指的不是说医院不正规,而是要多去看望安抚、陪伴疏导,要不对她而言就像是你把她关监狱里了似的。

哪怕是心理正常的人,被别人强制送进精神病院也肯定会觉得,这人是对你有恶意,更何况他侄女精神真的不稳定。
至于建议, 老实说我完全没办法, 您侄女由于之前的治疗和周围的舆论对去医院很抗拒。

我能想到的办法也就是,直接哄骗或者强制送去治疗,然后治疗过程中争取每日探望。
虽然这样在她心中你也成了“叛徒”,也会进入和她父母一档的恶人,但治病不能靠爱来感化,要是爱能解决那医院还开着干嘛。
只能在她治疗的时候多去安抚探望,别让她觉得你是把他送到了杨永信那里,期待某天她精神状态正常后能理解你的苦心。
看来这大众里大多数人还是认为已经确诊了的精神病人在生理上是没有异常的,只是心理疾病的问题,“只要用爱就能感化”。

说明教育仍需普及,虽然目前医学也没有搞太清楚精神疾病的原理,但普遍已经认为有许多中是由于内分泌异常等生理层面导致的,所以吃的药不全是说明镇定安眠的玩意,也有调节激素和直接就是某种类似内分泌成分的玩意。

有几个精神病人是单纯的心理原因,只能说心理压力是一种诱因,你没压力了她妹妹该被确诊还是得被确诊。
奥日和空洞根本不是一个类型吧。

空洞多少都还是需要考验操作的,我见到过许多人,玩茶杯头,玩空洞,玩魂 like 评价都不高。
1  2  3  4  5  6  7  8  9  10 ... 69  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1176 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 17:57 · PVG 01:57 · LAX 10:57 · JFK 13:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.