@liudaolunhuibl
> 你这不相当于 10 年前说智能手机没用的，手机就是用来打电话的要那么多功能干什么
当然不，你想想智能电视，想想安卓阵营每家一个的的「智能助手」，没有 10 年也已经出现至少有五年了，它们变好了吗，你用上了吗，以后会用吗

噱头的作用就是吸引眼球，没什么实际作用。我是觉得新电车上有很多东西都是这种性质的。 以语音控制尤甚。语音控制空调、语音变道、语音灯光……

还有些为了装饰丢掉实用性的设计趋势，像什么中控屏，还要带升降旋转，隐藏式门把手——这些甚至能称为糟粕。真要有本事把 hud 做好，实体按键触摸感做好，车机外接扩展做好。


反正我总有种国产电车是些互联网产品经理搞的东西的感觉，看着不太自在。
用一个意象形容我的感受——像是买一台四个轮子能坐着跑的小米手机。小米挺好，也是相当大区间最正确的选择，但离「精致省心」和「便宜结实耐用」都相去甚远

文件锁是内核处理的，不需要「共享」锁，只需要正确地访问文件就够了。

https://man7.org/linux/man-pages/man2/flock.2.html

个人感觉电车目前的「科技感」

跟「智能电视」「智能手机」的「科技感」差不多水平

乍一看很牛逼，多了解了解总觉得都是些卖概念博眼球的鸡肋功能，跟你手机上的语音助手一样，除了 siri 你们用过其它的语音助手吗……




多关注关注驾乘体验。 座椅、空调、灯光，音响，这些都是能带来体验的关键性部件，而这些部件都与电车 /油车无关。新势力们很多这些部分做得并不好，但给你弄个全连屏，你一看卧槽厉害被唬住了，但很可能座椅根本不舒服、空调根本不好用、音响差不说车机连个无损音乐播放器都没有，再冷不丁来点广告…… 是吧

你的发言完全颠倒了好几个事实，说明你……并没有什么正确认识

「没标准」完全就是错的，golang 里 http 库和 sql 库几乎是一切相关轮子的标准，轮子都在标准上拼拼凑凑而已

「工程问题交给程序员」也完全是错的，cmake 那才叫工程交给程序员，代码标准、格式化、测试框架、包管理都语言内置，你找找第二个？

「模板代码」不知道你在说啥，但 golang 连泛型都没有，是不可能写模板的，除非你在说用来写后端渲染的 template 库，但你自己想想后端渲染是主流吗现在。有很少工程会用代码生成器，但相关的需求往往放其它语言也得代码生成器。

「存在即合理」说的是你感知到了事物的存在说明事物的存在合乎你的理性模型，其客观存在能被投射成你的认知。

「存在说明它某种方向上是对的」是个完全傻逼错误的想法，一件事即使不存在任何意义或价值或正确性也可以存在。

「学什么不难呢」这种看法也全错，世界上出现过的语言就没几个复杂度能跟 rust 比的，golang 这种关键字比 c 还少的简单语法我是不知道怎么能放到一起去比的

/t/845966
https://i.imgur.com/5e5lctn.png

有没有一种可能，不需要把文件写到外存上，录在内存里直接发出去就可以了

我觉得短信实际上更先进

伪基站嗅探走一个验证码有啥用，你登录 session 还在发验证码的用户那呢

你是不是要这个 https://gorm.io/zh_CN/docs/has_many.html#%E8%87%AA%E5%BC%95%E7%94%A8-Has-Many
？

你写的是 list 转 map

然后你问 map 压平怎么压




你真的搞清楚你想问什么了？？？？


这个看不懂的话就没人能帮你了
https://go.dev/play/p/oje5ib9Pu-n

@Buges
日志里出现一个明文密码还是出现了一个 hash 过的密码，这个密码能不能用于突破登录只取决于日志的位置。「权限越少攻击面越小」非常对，可是把密码 hash 一下再传输根本没有减少任何权限。

拿你如此熟悉的 bitwarden 白皮书来说， 它用来什么手段减少第一方的权限？难道是 hash 一下 password 的功劳？
并不是，功劳是用户数据是加密的。加密用户数据才是减少权限的方法，它所做的所有这一切是保证加密是可信的。


你有没有想过
https://i.imgur.com/NIByveS.png
如果 HTTPS 不生效，这个系统的结果是啥


答案是，可以登录，但解密不了数据。



可以登录。

@Buges

> 假如你密码足够随机”你是不是忘了还有其他用户的密码不够随机？
totally agree. 所以前端 hash 的作用仅仅是帮助减少密码泄露的风险面而已，对验证这个过程的安全性没有多大帮助。












------

> 如果前端不发送 hash 后的结果到后端，我如何证明自己无法解密用户的数据？

所以你有没有发现你试图用「 zero knowledge ENCRYPTION 」去论证传输一个 hashed password 是 auth 的必要条件 —— 但这根本不是用于登录的。


其实从你 #28 拿出这个来附会撞库和加盐就能感觉出你好像混淆了不少东西

1. 套上任意多的密码学机制当然会「更安全」，但不一定都有意义。这跟 hash 一次还是 hash10 次没区别是一个道理
2. 不接触用户数据的后端并不是典型场景，零信任 /零知识不是每个系统的必要条件，也不是登录 /身份验证机制的必要条件
3. 我存了用户的 salted-hashed-password ，也不可能拿出来去其它网站撞库。被撞站点的数据库公开且 hash 过程相同且密码原文相同，这是一个极其苛刻的条件
4. 不管前端是否先对 password 进行 hash ，数据库里的 password hash 反正都是「零知识」（不能还原出 password 到底是什么）的。对于用户来说，自己的密码已经必不可能由于机制缺陷泄露到第三方了，仅仅是第一方是否有权接触到密码这个问题而已，那这其实跟第一方是否有权访问用户个人信息是一回事，都已经是与登录无关的另一个层面了


-----

其实有一个问题可以用来自我检验到底有没有想清楚：「如果登录过程完全没有用户密码，仅使用个人证书，会比在 SSL 中传输同等长度的随机明文密码更安全吗」


答案是不会。

@Buges 如果你没耐心都看完，可以只看这句话：

根据引理 1 ，前端 hash 一下密码没有任何额外作用。

@Buges 如果把「认证要素」（无论是 plain password 还是 access token ）视为 knowledge ，后端是无论如何必须知情的。后端不可能在不接触 auth chellenge 的情况下给出判定，因此「认证要素」是必须放在客户端信道中传输的。

换句话说，假如信道不安全，无论密码有无实现 hash ，中间人总是能复制出一个后端无法分辨的 chellenge 。chellenge 内容是 plain text 还是 hash 根本不重要，中间人能完整复制且通过后端验证。这是信道安全的必要性。

然后再讲充分性，即是否「只要信道安全则认证安全」；可以用其逆否来判断，即是否「认证不安全一定说明是信道不安全」。我们会发现存在比如「用户泄露自己的凭证」这种条件，所以仅当「泄露凭证」等条件不成立时才可以认为信道安全是认证安全的充分条件。（我暂时没想到其它条件，因此所有下文提到的「凭证泄露」条件都是此处反例条件的 并集，这个并集暂时只有一个元素。）


因此引理 1: auth 的安全性取决于信道安全，当且仅当凭证未泄露


第二步，我们讨论这个系统在任意情况下是否会导致凭证泄露。很容易会发现假若凭证存储等于凭证原文时凭证有可能泄露，而当凭证存储不完全独立于其它关联信息时（比如用户个人信息），也有导致泄露的可能性，其余情况不可能泄露。

因此引理 2: 当且仅当凭证存储的内容完全独立于关联性数据，且无法根据存储还原出凭证原文时，「凭证泄露」不可能发生


看这两个引理：
1. 当凭证不泄露时信道安全是认证安全的充要条件
2. 当凭证存储于原文和相关信息都完全独立时凭证不可能泄露

我们可以得出结论： 只要传输的认证要素与用户相关信息完全独立且信道是安全的，那么认证就是安全的。
用密码的一大问题是它跟用户信息往往存在相关性，因此使用密码原文作为认证要素有泄露密码的风险。但注意这不是因为脱库能拖出密码，也不是因为密码被撞了。我们现在讨论的是单一系统的安全性。是在说如果库记录完全公开了，这个用户的密码是否有被还原的可能性。如果他的密码本身就非常随机，即使库被公开了，密码也是不可能泄露的（不考虑 hash 被爆破的可能性）。

再强调一下，至此为止我们只考虑单一系统的安全性，不考 hash 能从已知明文撞出来的情况。



然后第三步，我们才来考虑多个这样的系统同时存在的场景。很容易发现由于引理 2 ，只要两个系统存在同样的密文，那么这两个系统就有可能发生相互泄露，因为此时「另一个库的密文」就是「本库密文」的相关数据了。换言之如果一个库存储的凭证被泄露了，是有可能发生另一个库的凭证泄露，从而破坏另一个系统的认证安全的。不过在单系统场景的假设下，凭证是可以不存在泄露可能的，即使凭证可以从一个系统泄露到另一个系统，但第一个泄露本身不可能发生。


综上总结一下我在实行和可得出结论的：
1. 前端加密没有用，因为它不增加信道安全性。顶多增加凭证密文的独立性，但假如我密码足够随机，在可信信道中传递密码还是 hash 过的密码有什么所谓呢
2. 多系统共用密码且共用了 hash 方法的话很可能会发生撞库，但只要保证每个这种系统即使数据库公开也无法还原我的密码，那我大可以就只用一个密码，想撞库，没材料。


3. 所以我现在的密码是分级的
- 垃圾不信任级：我感觉这网站的密码没准是明文存的，那么避免使用密码，只使用 otp 如短信验证码这种认证方式。因为对于这些网站来说密码根本是冗余的、无效的认证信息。
- 可信级，我觉得这网站的密码存储机制是足够科学的，即使库爆了应该也不能还原出密码。这些网站我全都使用同样的随机密码，因为记随机密码的心智负担有点大，我只能记一两个
- 高安全等级，存了我大量个人信息和记录的，绝对要杜绝任何认证被攻破可能性的，比如 google qq 这种，每个网站使用完全不同的密码，我有一套生成规则

4. 我不使用密码管理器。因为无非是把撞库风险面从远程服务器转到了个人设备上。而个人设备很容易使人掉以轻心，比如相信不少人密码管理器的 pin 就不会很复杂了对吧

5. 开发要登录的业务系统，不进行任何传输层上的变形，比如什么前端 hash 这种，没用。when in need 套 TLS

买给自己玩还是孩子学

孩子学我不知道

自己玩别买电子琴，买 midi 键盘，编程控制多一点的，然后接电脑玩，音色直接甩内置音色 10 条街
（不会这时候有人正版出警吧）

我倾向于以结果命名而不是动作

比如我会写 flattened() 而不是 xxMapToList

你说的 1 的情况不知道是不是 [{key:"k1",name:"n1"},{key:"k1",name:"n1"}] => {k1:"n1",k2:"n2"}，如果是，那么结合我猜你这问的是 CRUD 逻辑的上下文，我隐约感觉你代码逻辑结构不太对，要么是 查询其实可以多做点事，要么是数据传输过程中多了不必要的结构转换（比如，其实应该让前端自己转）。我几乎没写过 list to map ，只有 map to list

2. 我会写

var goupedScope = func(args...) func(tx) tx {}
byXXX := groupedScope(XXX)
q:=db.Scopes(byXXX(db), ...).Where().Find()



----

golang 没有 lambda 「表达式」，可是有匿名函数啊。所有这些转换函数都会污染整个 package 下其它文件的函数命名，所以我应该不会想把它们真的写成一个函数

@qrobot 我好奇的正是「只要你自己能看懂能理解」←这些个人到底能不能看懂能不能理解。

而就这楼的情况来看，存在混乱并不完全理解自己需要什么的人的比例比我原以为的要高得多。



多 r 少 r 当然说明不了什么
问题是你真的只是打错字么？

你猜我给的代码里，后面他写「 router.push 」的时候能不能分得清

- 往路由表里增加一个条目 or
- https://router.vuejs.org/zh/api/#push

?

中文的等效物应该是 —— 字体设计师一直在研究和从事的方向