表单提交，测试时发现重复点击后，造成后台数据重复问题，到底是前端的工作，还是开发人员的工作？

[Trinity888]

前端开发人员：只负责静态界面、表单校验及相应界面跳转、交互效果的实现

后台开发人员：负责业务逻辑及数据动态内容开发

现测试人员发现：表单提交时，重复点击多次提交按钮，造成数据重复问题。

现在分析：

1 ） 表单提交按钮控制，谁来做？

是前端没有把界面验证做好（例如按钮只能点击一次），还是后台开发没有控制？

2 ） 什么阶段来验证？

前端开发完成后，没有验证测试通过，还是后台开发人员全部完成后验证？

[xuanbg]

前后端都要做防重复提交！前端主要是点击后禁用按钮，等接口返回结果后再解除禁用状态。后端一言以蔽之：接口幂等。

[JustinJie]

前段防抖, 后端幂等

[rekulas]

@otakustay 重放请求跟 csrf 似乎没有关系，csrf 是数据验证导致的问题而不是重放

[shawndev]

后端必须做，前端建议做

[pigzzz]

前端做是为了体验
后端做是为了安全

[yeahvov]

后端必须做 前端不闲的话也可以做

[romisanic]

前后端都要做，必备的基础。
产品设计的时候，也应该考虑到点击后按钮的状态和防抖等，如果没有，那产品也有锅。

[yiqunz]

都得做，别说什么前端只是建议，
假如是内网或者没人攻击的系统，前端做了就直接能避免重复问题了，可以降低服务端压力（有的用户就是骚，一秒不返回我就疯狂点按钮）
当然考虑安全性后端是要做的，实际情况是很多内网项目宁愿前端加个按钮失效也懒得后端做。
就跟必填字段类似 前端不做 每个字段都来请求后端返回错误，也是挺搞笑的，至少我没见过这样的产品。

[gengzi]

幂等

[otakustay]

@wangxiaoaer 请求重放是很典型的 CSRF 攻击之一啊

[otakustay]

@rekulas 我的理解是，CSRF Token 不一定能解决重放的问题，但重放是 CSRF （客户端请求伪造）的一种。只是这种伪造不是基于攻击需求的带逻辑的伪造，是纯粹地拿已经发送过的请求作为伪造结果来用

[rekulas]

@otakustay csrf 是 Cross site request forgery，严格来说我觉得单纯的重放不算 csrf，不过 csrf 是可以避免重放攻击(这是当然的 这其实是废话)

[whisky221]

“到底是前端的工作，还是开发人员的工作？”

前端再次被害，果然后端的眼里前端就不是开发，还好我正在转后端 ing

[wc951]

两边都要做，前端是为了用户体验，后端是为了数据安全

[tpsxiong]

@rekulas 后端不做，如果 2 个人同时想取一个相同的昵称怎么办，而昵称又不能重复

[Felldeadbird]

主要责任在后端。

[weixiangzhe]

前端 debounce 加 loading 和 disable 可以处理

[kaiki]

我前端后端都写，但是我前端后端都会加验证。
后端不要相信前端发来的任何信息。

[dawniii]

看场景

1.假如是今日签到的按钮，后端肯定要做禁止重复签到的检验。

2.假如是后台发文章的接口，如果后端有标题不能重复的判断，自然也就没法重复提交。

3.假如还是发文章或者评论，并没有什么业务上的字段非重复要求，后端就没必要特殊处理，就算处理也是防止灌水处理吧。

以上所有场景前端肯定应该做按钮 disable 处理的，前两个场景是正常的错误提示，最后一个场景是防止非预期的“灌水”。

[Balthild]

都做。后端做来保证数据一致性，前端做来改善用户体验。