修改密码表单中的"请再次确认新密码"字段需要一起传到后端吗

[LoremIpSum]

个人感觉不需要，因为前端已经校验过了，后端再做一次 equlas 判断感觉没什么必要，但是看到有些开源项目也把这个字段传到后端做校验？请问把这个再次确认传到后端起到什么作用？

[vkhsyj]

没必要，但校验两次也没啥问题

[shiji]

@delectate
接受历史密码和其他网站通用密码是万万不可以顺利登陆的。。那是安全灾难。。

[racecoder00]

加个显示密码的按钮，取消确认密码框，完美

[Torpedo]

其实所有表单验证前后端都是要做的。

[charlie21]

背锅论可笑？你背锅就开除你，开除是不是也很可笑？没饭碗是不是也很可笑？正好可以放假三个月 非常好

可以去西藏

[DeutschXP]

这个问题其实很简单：
最早的时候是没有重复输入密码这个概念的，之后由于密码框是星号，很多人会输入错误，为了解决这个问题，也为了用户体验，引入了这个设计。
所以这个设计的作用，主要就是防止用户输入错误。
那么，如果现在要取消这个，无非几点：
1. 用户不会输入错误了，比如上面所说的，可以明文显示密码，而不再用星号遮盖
2. 无所谓用户是否输入一致，不行就重置密码 -- 这等于是个倒退的设计，所以不可取。

那么，如果还需要防止用户输入密码不一致，就必须要保证这个功能能够完成。这也牵涉到了另外一个问题：后端不要完全信赖前端传过来的任何数据，都需要重新验证。

现在的同学可能无法理解十几年前大厂的网页开发，严格意义上必须要保证浏览器在不支持脚本的情况下，也必须要能完成所有功能。
前端的任何 JS 校验，都只是为了用户体验，没有其他意义。上面很多人说，没重复验证的必要，可能是过于信赖前端了。就不说什么安全性了，很多人忽视了稳定性和兼容性。即使是自己的 App，都无法保证能够前端校验运行一直正常。而网页+JS，就更无法保证了：
- 某个终端的某个浏览器版本，可能对你的前端 JS 校验代码并不完全兼容
- 某个 bug 可能会导致 JS 代码运行不正确
- 甚至是网页没有加载完全，某个插件出现异常，都可能会导致 JS 校验不工作
。。。。等等等等

你可能要说了，如果 JS 代码没有工作，好像也没什么安全问题啊，最多用户两次密码输入不一致，用户无法登陆呗，不是大问题。

那么，请重新阅读文字的最初，这个设计的目的是什么，就是为了给用户更好的交互体验，防止用户输入密码不一致。那么，前端不传数据，后端不校验，那么就可能有 0.01%的可能性无法实现这个目的。好像也没那么重要？但如果传递了，后端验证一下，并不麻烦，但可以把这个概率降低到了 0.0000001%，那么为什么不传递，非要弄一个不稳定的半成品出来呢？

[AV1]

@loading
@no1xsyzy
这里不需要去抖。简单的字符串比较，每秒不到十次的触发频率，既不涉及 IO 也不涉及图形绘制，无论去不去抖，放以前最弱的 IE6 都没感知区别。
另外检测事件应该用 oninput 和 onchange，而 keyup 会丢失剪切、粘贴、拖拽的变动。

[dcsite]

我认为确认密码这个输入框本身应该去掉，没什么意义。
一般的网站本身设计了重置密码功能，无法登录时肯定重置密码。特别是现在 Chrome 自动生成密码功能，对于二次确认密码来说，多此一举。

综述：上古时期设计，用户体验不好，本身该功能就应去掉，后端也无须检测。

[loading]

@DOLLOR oninput 和 onchange 是都绑同一个函数吗？还是二选一也行？

[IvanLi127]

个人觉得没必要传，这不妨害系统安全。前端校验规则执行的时候翻车了，那也只是意味着帮助用户减少手滑打错密码的功能丧失了。不过都严重到校验规则跑出问题了，是不是要考虑用户还能不能跑得起来界面？

[AV1]

@loading
选一个就行，这两个只是触发时机的区别。

[no1xsyzy]

@DOLLOR 不存在的，Electron 在 ibus 下会 input 和 change 事件。还有页面注入脚本的密码管理器，不一定全都设计为主动触发事件，尤其还需要特地构造事件对象，然后再发送，这么复杂——虽然密码管理器不太会有不一致的情况。
…… 不过主要还是 Progressive experience 吧。

[no1xsyzy]

@IvanLi127 是的，Progressive Enhancement （上面写错了……），你其实需要担心用户是否可以加载 JavaScript。而且实际上 CSS 比 JavaScript 快（得多）。