代码要用版本控制，比如 git。

很多 APP 都会在 Wi-Fi 掉了之后，自动使用蜂窝网络。

但是流量占用比较大的，会提供不使用移动流量的选项。

「文章本天成，妙手偶得之。」

@elyamen 不如 v4ex

关掉 v2ex.com，那个人就访问不到了。

@xav1er ?

@zhaoxiting1997 get 的合适用法，应该是可多次请求但基本不会改变其数据的资源。比如读取文章（尽管可能更新阅读数）；至于增删改，因为对数据影响比较大，一概用 post。响应了 post 请求之后，应该 redirect 到一个结果页，以防刷新页面引发重复提交。

装个 Ubuntu ，几条命令就好了……

鉴得多了，就成了黄牛

@jsq2627 那这样是正确的用法吗：HMAC(myFunc(originalHash, salt), randomString)

@wy315700 昂……是的啊。所以说，在安全策略不允许明文存储密码的前提下，客户端要实现对应的加密算法才行呢。

引用 @wy315700：
「你这样如何检验密码正确性，每次提交的MD5都不一样。」

服务器也用这个随机数，和之前存储的用户密钥放在一起，用相同的算法计算结果，与客户端相同，则认为其是授权用户。所以，在上面我也说这要求客户端也实现加密算法，从而不适用传统 Web 应用。
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code

@wy315700 hmac 里服务端生成的随机数，才是其关键吧！这样不用传输敏感的密码原文，即可完成对密码的验证。

如果只是因为盐与密码原文拼接后有碰撞，而采用 hmac，我觉得大可不必，因为：

1. 盐由服务器管理，每用户唯一，对于单个用户来说，因为盐是固定的（如 ef），所以不存在相似密码与盐拼接后碰撞的问题（abc 永远不会通过验证，盐不可变更）；

2. 盐在生成时，可以技术手段保证位数相同，不给掌握密码前半部分的攻击者以瞎蒙之机；

3. 在用盐计算哈希值时，可以用明文与盐的哈希值拼接，然后再取哈希值。

@stiekel 关于 md5 这段，我突然想到：

如果「浏览器端对密码进行md5」被普遍采用，一旦 md5 值被截取，那将势必「影响到用户在其它场合中的密码安全」。因为密码作为明文输入 md5 函数做参，得到的摘要是一样的。所以，要想各种场合密码互不影响，则要保证：

每一个应用，各自采用不同的 md5 加密次数，你两遍我三遍，猪八戒三十六遍、孙悟空七十二便，以保证网络中传输的 md5 值不被用做其他场合上。

所以，与其这样，不如也在客户端「加盐」，只一遍 md5 就不会影响到其他场合了。再进一步，如果每次会话都由服务器生成一个随机数，作为「胡椒」加到明文后面做出哈西摘要拿去验证，那么，「别人拿到这个md5」也因为再次请求时随机数不同，而不能「直接在应用中登陆」了，岂不更妙。具体实现上，可以参考 hmac。

@zhicheng 可不可以发一篇博文之类，让更多人学习一下？