@yjxjn 是的，我就在日本上班

为啥别看个 pwm 调光就害怕

一直诟病的都是一两百 hz 的低频 pwm 调光好不

lcd 的 pwm 调光频率可是几千 hz 起跳的

养猫和用电脑是冲突的。猫掉毛很严重的，无论是台式机还是笔记本，过段时间你电脑风扇还有内部都会被猫毛塞满

不是，我寻思 Windows 命令行里也没有回收站这功能啊？
为什么觉得 Linux 命令行就要有回收站了
回收站不过是桌面提供的功能罢了

就 switch 那性能，，，，除了任天堂本家根本没几个第三方能在上面整出花活的
比如常年性能优化垃圾的米哈游，当年说元神要登录 switch ，我是根本就不信的，因为就米哈游的优化技术水平，上 switch 简直就是做梦

所以意思是 Windows 每 5 秒就截我屏然后发给微软的服务器做分析？？？？？
如果不给个本地模型版的话鬼才敢用你这功能

从写代码成为负责项目需求听取定义，设计等等的 SE 之后，我最大感想就是我他妈好想当回臭写代码的啊
一天到晚就是做资料，写计划书，定义书，仕様書，时序图，流程图，随时管理了解各种功能等等等等，太 tm 心累了

想躺床上看电视，电视必须挂地非常高的，要不然就是长时间低着下巴看电视，对脖子影响非常大。lz 你自己试试躺床上或葛优躺的时候，你视线是往哪放的

真就治标不治本呗。。。。。。

你自己手撸追踪吗，你确定能解决好下面这个问题？
请求从进入服务器代码那一刻开始，算一个周期 A ，然后进入 controller 到出 controller 是一个周期 B 。B 是 A 的子周期，同时 controller 里调用 service 从开始到结束是另一个周期 C ，周期 C 是周期 B 的子周期。随着你服务的复杂，各种父子周期嵌套，你怎么处理记录这些数据，然后怎么写一套机制让 trace 能比较简单地能在你对应记录的起始和结束部分打点

最后一个请求里各种父子周期请求你怎么处理展示。这些都不是把数据塞进数据库就能解决的

而且 OpenTelemetry 除了展示，统一标准接口，还能和 aws xray 这些良好结合。我负责的几个项目就用了 xray ，挺不错的

@CloudMx 一个网站的前端后端不是割裂的，不知道为什么你会如此不自觉地将前端和后端如此割裂地来看待，一个网站往往是同一个公司的人写的，有的网站前端后端写代码的甚至是同一个批人或同一个人。可能你用的网站的前端就坐后端边上，两人还天天中午出去吃饭聊天打哈哈。我说这么多只是想提醒一下，一个网站的前后端往往联系是非常紧密的。对于一个整体的网站，当出现内部恶意第三者的时候，你要考虑的就不光只是密码这种微不足道的东西了。

再次整理一下，你完全不信任一个网站后端觉得网站后端就是有恶意的可能想搞到你密码，但同时你又很奇怪地完全信任这个网站的前端，认为这个不安全的网站的前端是完全的好人把你的密码 hash 一下之后你的密码就安全了。所以你认为前端 hash 一下等同于从后端那保护了你原始的密码原文，对不

但我的看法是，是的 hash 一下你说完全没用那是假的，但我上面也说了很多了，前端 hash 这件事本身就没多少用处

@CloudMx 等等，你怎么偷偷改了话题？ 话题怎么从防止密码原文入库变成了「这个网站它如果是是恶意的，它就是要想办法搞到我的密码原文去作恶该怎么办」了？ 前者是纯技术话题，而你 19L 的这个话题则并不是技术话题，而是变成了网站内部有恶意第三者搞破坏我该怎么办了。

假设一个网站隐含有主观恶意，它就是要搞到你的密码明文作恶，那么为什么你会觉得这个网站的前端就是安全的？哪怕这个网站的前端登录时把你的 password hash 一下，给了你一种虚假的安全感，它也有一万种方法再变相把你的密码原文发送给服务器。甚至后端想作恶了它都不用动你前端，直接拿你令牌就是了。对于一个有恶意的网站期望密码 hash 就能保护自己的密码原文本来就有点奇怪。这种时候你还不如一个网站一个随机密码实在。这相当你“人肉做了 hash”

@CloudMx 对于后端来说，前端无论传的是密码原文还是 hash 后的值，在后端看来那都是“明文密码”，这点你能反应过来吗？比如用户密码 123456 ，sha256 一下就是 effff....16c 。那么对后端来说，effff......16c 就是明文密码。我是个攻击者，知道了你这串 effff....16c 直接用这个值请求登录 api 就登录进去了。前端你 hash 不 hash ，结果和明文密码并没任何不同


然后这里还有个问题，你有没有考虑过加盐 hash 到底应该在哪一步才好？
方法 1. 前端传密码原文，后端加盐 hash 入库
方法 2. 前端加盐 hash ，然后直接将结果入库

这里，比起方法 1 ，方法 2 是存在极其严重的安全漏洞的。加盐 hash 保证安全的前提是“盐是保密”这一点，前端加盐=盐被公开，当你盐被公开而后端又直接入库的话等同于用了方法 1 但后端的盐泄露了的情况。
所以前端加盐 hash 为了保证安全，那么你后端必须要再用另外的盐再 hash 一次：
方法 3. 前端加盐 hash ，后端再用另外一个盐 hash 入库
这时候方法 3 本质上和方法 1 并没任何不同（因为对后端来说无论你前端传什么过来对后端来说都是密码原文），只不过从一次 hash 变成了两次 hash 。那么这就又有个问题了，你都搞了两次 hash 了，为什么不为了安全后端多来几次，3 次，4 次，10 次，100 次？所以仅从数据入库角度来看，前端 hash 不能说脱裤子放屁，那也是没用处的

@CloudMx 4202 年了，哪个厂商后端还会直接把拿到的原始密码直接入库，学后端开发自己手撸用户模块的话所有教程第一节课都会教你服务端要把密码 hash 后存储。用的如果是正经的现代框架的话，我反正没见过现在什么主流框架的用户模块会直接往 db 里存未处理的密码原文的（如果真有的话建议说出来让大家开开眼，估计这框架将会成为开源界的耻辱了）

@Jirajine so ，你的论点是什么？ 这里讨论的是中间件日志被攻击的场景，以及由此产生的安全隐患。lz 认为密码不能明文传输的最大论据之一就是这个。所以我结合自己的实际项目经历指出了 lz 论据根本站不住这个点，请问哪里偏题了？我的问题和质疑点还是没变，你都不信任中间件了为什么还只关心密码泄露这种小事？

@Jirajine 啊，对了。。。有一点差点绕进去导致我说漏了，lz 你再仔细想一想，当中间件真的输出了你的密码请求体，请问这时候输出明文密码还是 hash 加盐之后的密码有非常大区别吗？

按照 lz 的想法，需要在前端完成加盐 hash ，那么这个“盐”必须要存在网页或 js 代码里吧，那么对于一个都有能力去攻击你系统内部中间件的人来说，浏览器 F12 看一看你前端登录时用了什么“盐”是很难的事情吗？
这时候攻击者有了盐值，也有了中间件输出在 log 里的 hash 后的值，他要做的就只是跑一个彩虹表的事情。对于不复杂的密码这么做和明文是没区别的，该撞库你还是挡不住。而对于复杂密码的确彩虹表是跑不出来的，但一般非常复杂的密码往往都是随机生成的密码 or 用户根据自己一套规则生成的动态密码。你哪怕跑出来也没办法拿去撞库

再说一下，后端密码入库前必须加盐后再 hash 才会更安全这点，原因不在 hash 上，而在于 “盐是保密的” 这一点上。后端的盐除非出了致命漏洞被黑客侵入了服务器内部，一般来说是根本不会泄露的。因为“盐保密”所以这种做法才是安全的。而在前端加盐，这个盐是明文公布给所有用户的，也就是说加盐等于没加。