你写的是 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

?

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

> 自己从小到达基本只玩网络游戏，梦幻、穿越火线一类的，LOL 都不怎么玩


我的建议是……直接卖了吧
这就跟从小停古典流行金属养成的 taste 一样，过后就很难再品尝到其它风味了

上个世代 ps4 是全世界最好的蓝光播放器，即使不玩游戏淘电影光盘来看也能继续发挥不小的作用，但这个世代有异常能打的 xsx ，所以 ps5 不再是唯一选择了



主机游戏的体量都是很大的，想要好好玩完一款游戏动辄需要几十小时的时间。玩主机游戏得有好好看一下午电影的心态，得有时间。然后建议从一些线性流程有剧情的游戏玩起，比如 the last of us 、 神秘海域 、战神 这种。或者可以尝试交互式电影，底特律变人、隐形守护者





一定要有个客厅的大屏幕躺客厅的沙发上玩！ 不要用电脑屏幕！

我几乎没用过触摸板三指之外的其余任意切换方式

三指上划=所有程序平铺
三指下划=当前程序的所有窗口平铺

这不比什么键盘鼠标都快太多了


另外继承自用 linux 时候的习惯，我给鼠标设了一个触发角，能减少在 dock 栏里找东西的时间

@David1119
192 typo 看笑了，建议下回截图想办法把行号也带上

@vchroc
@vision1900
@jaredyam
@baobao1270

其实我正是想知道写出这样代码的人是单纯的英语不好还是概念搞不清楚。

如果说「虽然名词区分不清但概念还是清楚的」那忍忍也就过去了

但如果写代码的时候分不清
「增加一条路由条目」
「跳转到新路由」
用到的是什么东西

那就没法忍了



比如我就看到里面写着
router.push({...})
但 router 其实是个 route array
然后他又没写 routers 复数写的是 router


就不禁让我怀疑他是否搞得清自己在修改路由器还是路由表。





所以我想问问大家从概念上也好从单词上也好，分不清的是不是普遍现象

？

http://cnm.buhuibaidu.me/?s=golang%20%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%20site%3Acsdn.net



https://github.com/stretchr/testify
https://go.dev/play/p/kIZkoT2EvJX
https://imgur.com/a/2V262Su

@murmur
@JamesRuan

所以币圈的链没卵用，但完全可以再创造出些新的、有用的、能承载内容的链，这是没问题的

我讲一个这楼里所有人都忽略了的点


虽然他们的电脑只有一个分区


但他们有 NAS……


他们的数据都不在电脑里，电脑里只有应用。明白我意思不


我一个 D 分区跟了我两台电脑 4 块不同的硬盘，它的旁边存在过 win8 、ubuntu18.04 、win10 、无分区空间……甚至从磁介质迁移到了电荷介质又回到了磁介质。反正我能确定如果没分区这些数据活不了这么多年。怎么还有人说备份比分区重要，我 tm 分区本身就是备份的层级之一！

我为什么要格掉 C 盘？
因为它要变成 ext4 了
因为重装还是在崩 bcd 引导，我是不是得格掉试一试
因为我准备把系统用另一个硬盘装了，格掉扩个容

「分了区硬盘一坏还不是全没」跟「分盘备份 NAS 一坏还不是全没」不是一个逻辑吗，你说不考虑 nas 崩，那我先不考虑硬盘全坏先把区分开不也有一定作用吗

备份是吧、备份、备份（藏狐拍镜头.gif ）
不格盘、不格盘、不格盘（拍镜头.gif ）

web3 靠谱跟做 web3 的公司靠谱不是一回事

如果把 web3 定义为如下概念集合： 分布式内容提供网络、self-hosted 、serverless 、复杂图数据库…… 那感觉还挺有盼头的

但如果跟你吹 web3 的是什么执意附会区块链的鼓吹者，那我先放一个过去的回复： /t/812505

20 年前，世纪初的时候人们早已经尝试过很多种「真正的分布式网络项目」，比如 seti@home 这种分布式计算、emule 这样的分布式 sharing 。但受限于那个时候的网络和主机性能这些项目放到今天来比只能算雏形。


在今天这个随便一台个人主机都足以承载上千 qps ，上行带宽能达到 10m 以上的时代，我感觉是很有希望能把过去的那些实践重新发展到新高度的。参考 50 年前就已经出现的「神经网络」。毕竟你都愿意浪费上 T 的空间或者两个 3090 的算力去算一些没意义的东西，如果把这些资源用来 serve 一个「有用的网络」，应该很有可行性才对。


我就希望搞区块链的那帮人什么时候能别盯着它那点破 token 那些个鸡掰 proof of something ，一个能永久更新全网同步且不丢数据的零信任分布式数据库，他们居然只用来玩算数游戏！