你好像不知道你贴的所有 json 都不叫「一个列表」

@olddogs 你贴了 4 次代码都没解释清楚源结构是什么目标结构是什么，我真的服气。

#15
> 是的，就是打算把树状拍平，有咩有办法啊? 大佬

查询出来的 list 是平坦的，你到底要从 k-v list 拼出一个树还是要把深度>1 的树平坦化成 k-v list ，至今是矛盾的。



你给了这么多示例的 json ，全完全不提表结构是什么，最后一次贴的这有上百个不同单词的 json ，你想让别人怎么心灵感应每个单词 /字段从哪来？




其实上面这么多回复，有灵性的早都可以想出来了

1. 并不需要 map[string]map[string] ....，map[string]interface{} 就足够了
2. children 这种嵌套可以用自引用模型直接在查询时查出一个嵌套的结构体
3. 你第一条附言给的数据 flatten 的代码给你了，你试了吗
4. gorm 的文档你好好看了吗，嵌套 preload 你看到了吗

@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 下其它文件的函数命名，所以我应该不会想把它们真的写成一个函数