> 登录的业务本质是什么？就是验证身份，成功之后开启一段会话

明明你「理解」了本质，怎么还能想出这种结论。


假设你们的系统真的能先收到登出再收到登录，登出的时候，会话在哪？





> 么当先收到登出消息时，无非就是发现这个会话没有开始时间么，但是他确实是一个存在的会话啊，没有开始时间就没有好了

哈？ REALLY? 你是凭什么认为这个登出消息能是一个合法消息的？

fstab:
https://superuser.com/questions/1710001/how-do-you-configure-windows-subsystem-for-linux-2-wsl2-to-use-fstab-to-automa

@dangyuluo 那也可以依赖一个只用来延时的空服务

colab 的官方 tutorio 都很详细了：

https://colab.research.google.com/

colab 就是个在线 host 的 jupyter

补充，被依赖的服务可能需要恰当的 heath check 方法

https://i.imgur.com/ZfynF92.png

贴错图链接了

https://imgur.com/a/uhEzyr3

B 视角： 第 9 年放钢板第 10 年撞
A 视角： 第 13/3 年放钢板第 6 年撞

有没有想过 svn

@z1645444 都是用你出生时的公民 ID 做随机种子算好的，你只管赚够信用分就能换到。

三层网只防误触不防作死，他要伸指头进去玩照样被电

所以教育>保护

你让他看着蚊子怎么被电成烟的，拿个螺丝刀什么的放一放电噼里啪啦吓唬一下，教育他这东西很危险不能碰他自己是不会敢去玩的。

如果是还不懂事的很小的小孩，那最好的办法是收起来别让他看见。

放弃微不足道的手感问题

买那种办公用的超薄笔记本式键盘，那种玩意怎么敲都没声音

其实对请求签名防范的最核心问题是，你有些时候并不能保证请求内容和 token 来自同一可信源。举个底层逻辑相同但作用和机制完全不同的例子：CSRF token. 为什么明明用户都已经登录了，请求者拥有该用户的一切身份证明，为什么服务器还是不能完全信任这个请求？就因为服务器不能确定用户提供的身份证明能否证明他发起过请求内容。而通过下发 csrf token ，可以保证持有 session 凭证的所有者才能发起合法请求，这就能确认身份证明与请求内容是同一人发出的。


签名同理。

@musi 我通过一个*SRF 漏洞修改你的账号发言权重

@julyclyde 证书就是签名，双向证书==双向签名，机制稍有差异而已


----

我问个问题。

你是腾讯的服务器，现在有人请求修改 onwer A 的资源，你需不需要确认请求者就是 A ，如何保证？

玩过，一句话，除了不好玩其它都挺好的

我最近买的新手机号能收到银行发来的欠款通知短信，银行还打过来问我是不是 XXX （实名）


但我登录不了这个人的微信，就因为有这个好友验证。

@studyrun 链路上的同网段机器不需要经过路由器转发。所以桥接和 NAT 不应该会有区别。

我的 wsl 和宿主机就是桥接的：

https://i.imgur.com/4oIsQJq.png

@bk201
> 人家就是混口饭吃，也是朝不保夕，被开了还没赔偿，你还能对对方有什么要求。

你知道 wuli 外包哥哥有多努力吗，你们非得看到他进监狱才开心吗