- 主题:jwt相比普通token,优势在哪?
说实话,个人觉得就一个系统怎样都好,就算一个 session 有10k的信息,也轻松达到单机上百万个用户
要是有5个独立的共享用户群的系统呢?哪怕是 web 也可以直接 jwt 然后 cors 访问其它系统 api,这不就省出来5套 redis 了么?
【 在 haili (人尔有窍 风吹为籁) 的大作中提到: 】
: 说起来4年前用play的时候,就见过它们鼓吹的stateless,确实也相对方便一点,逻辑也是secKey hash签名加上数据存客户端传递。JWT算是一个更加公开和规范的版本。
: 业务要求无需登录,APP级的最好直接上指纹等原生安全方案存登录信息,嵌入微信/支付宝就依赖平台的oauth能力按说也够了。
: 不过前面有人说redis不适合session或者是分布式redis很难?不知道何解?
: ...................
--
FROM 122.60.88.*
谁知道了,如果用个 jwt 这么难
【 在 exbf (忘记我,向前进) 的大作中提到: 】
: 是啊,如果用个redis这么难,那前面有人为了解决invalid token问题连消息中间件都用上了,还觉得这个代价轻,用的很普遍。我就呵呵了,会比redis更普遍吗。想起一个成语,叫削足适履。不说jwt有没有用,但如果你确实需要invalid token而把消息中间件加上的话,还是老实
--
FROM 122.60.88.*
我这不是为了说明对于客户端来说,jwt 跟 session 是等价的么
突然意识到了一个问题,可能因为我在墙外呆久了,跟墙内讲的安全不是一种概念。
一边用着老版本 ie 甚至 xp,flash 还在大行其道,然后谈安全……我们客户如果问为啥不支持 ie11 之前的版本,只要一句微软已经不出安全补丁了就怼回去了。上上周 chrome 好像修了个 0day 漏洞,我们不是技术出身的总经理群发了一封邮件提醒升级 chrome。
这个月初给一个斐济客户的大概能有7、8年的老系统加个 js 限制,因为我们后台有个 bug,某种类型的东西同时添加多个,只能保证一个能生成正确的记录。已经不给老系统做功能上的维护了,这个只是为了避免客户误操作,大家都开心。因为不了解前端用了哪些东西,我打算用 vanilla js 写,然后就想看看用户有多大比例用 ie。因为没上统计库,没办法看了另外一个产品在斐济的客户数,月平均1、2个 ie 访问,于是我就放心大胆的写了。
上周还有个客户报 bug,说是小键盘的“.”在货币的文本框里不能用。客服一问果然用的是 ie11,然后就劝,除了 ie 以外的都没问题,于是客户就换了。因为我用的是 mac 不想开虚拟机了,于是随手在 codepen.io 写了几句发给同事让看一下 event.key 是什么。结果同事打开链接,人家默认不支持 ie,虽然给了个视频链接似乎可以在“old browser”上面用。虽然这个 bug 现在还是要修的,但等再过个两年 ie11 的生命周期结束,我们就可以宣布不支持 ie 了。
另外,类似 github 说不支持就不支持 ie,所以墙外的世不支持 ie 也无所谓的,更别说都多年没碰到过要开 flash 的了。
客户的安全需求也是千奇百怪,有 openid 的,有 ldap 的,有的是公司内网,我们得用他们给的 token gen 远程桌面登录的。不知道 oracle 密码自动3个月过期的功能有没有给生产环境关掉,反正在开发环境上我是吃过亏,折腾了好一阵才给关掉。我们这责任很明确的,如果问题的原因在我们,那没问题免费给技术支持。但是如果是 auth token 泄露这种问题,明显责任不在我们,想让我们擦屁股,没问题商量个价钱吧。而且按照我们的客服条款,保证正常客户流程没法满足这种安全需求,而且我们是工作时间客服,不提供24小时客服的。你想要快速反应,24小时服务,肯定不如多养一个人做好公司的安全问题划算。
cookie 设 http only 有它的好处,当然缺点是失去灵活性了。但是按照目前主流浏览器的实现,是可以保障 js 没法读到 cookie,这在安全方面是非常有意义的,尤其是在使用外部 cdn 的情况下。
另外像 csrf 纯粹就是个保护色,抓到网页看到有 csrf 就知道不用动这方面脑筋了。莫非低版本 ie 还能跨域名 post form,所以还在纠结这种早就失去意义的安全问题?
一边用着不安全的工具,一边要把一个 token 签个三年或者天长地久,然后还一边喊安全,我觉得挺有喜感的……
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: jwt一般也不放cookie吧,我见过的项目一般都是走http header,这样的方案在native app端和web端通用,后端不需要分两种情况处理。web前端持久化大多数也是放localstorage。cookie这种远古浏览器黑盒子,黑魔法太多,应用层不能主动控制细节,不同浏览器行为也有细微区别
--
FROM 122.60.88.*
你觉得 csrf 攻击怎么高大上了,你们网站利用了 invalitable csrf token 解决过什么样的攻击,让大家见识见识。我也问了你们 py 或者你自己又怎么实现的 csrf,也大概介绍了 rails 是怎么做的。你啥都不说,只是单纯说重要,阴阳怪气的给人扣帽子,你不觉得自己这种回答很没品么?
都9012年了,难道没 csrf 你们的 web 还会被简单的 get request 攻击?这水平的网站还谈安全不是搞笑么?
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 不是墙不墙的问题。以 apple 版人人是产品经理,个个是乔布斯的心态来当程序员,当然会觉得这个世界真奇怪。
: 业务需求和软件技术一样。也有适用和不适用的场景。
--
修改:eGust FROM 122.60.88.*
FROM 122.60.88.*
这个世界的确很奇怪
https://caniuse.com/#search=samesite
等 ie11 安全支持结束之后,我们的网站就可以正式让 csrf token 退休了,然后老鱼的高级产品经理的网站还需要 invalidable csrf token
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 不是墙不墙的问题。以 apple 版人人是产品经理,个个是乔布斯的心态来当程序员,当然会觉得这个世界真奇怪。
: 业务需求和软件技术一样。也有适用和不适用的场景。
--
FROM 122.60.88.*