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

前后端都得做。

后端不能相信前端，前端也应该做控制，所以应该是都有责任 /狗头

后端必须做，前端建议做。前后端连调通过再让测试验证。

都有责任。前端提交时按钮要 disabled，提交成功后要清空表单，提示成功，阻止重复提交。

后端要验证，防止出错重试或者恶意导致的重复提交，比如二次提交加验证码，比如限制两次提交的时间间隔。

硬要分锅 我觉得是后端占 80%

就算前端只能点击一次 api 直接一秒 call >100 次呢

都要做，当然如果是赶工出来的，那就是正常。
如果是开发时间充足，两边都要做。

前端提交表单后，提交按钮变为不可点击
后端做 CSRF

前后端都要做相应处理。
只要没有事先约定。
后端要默认前端是啥也没做的
前端要默认后端是啥都不想的

我个人觉得后端再不相信前端也不做这种防错吧

重复表单如果有业务逻辑可以判断重复那后端肯定要加验证

如果没有的话,就是前端的问题啊, 点击提交按钮禁用显示加载动画 等后端处理完 再显示结果+按钮可用就好了.

后端的问题,表单重复提交这问题起码十年以上了你就不能百度学学怎么解决?

都得做，后端一定做得要更细致点。前端做可以限流

幂等性设计啊

后端需要随机 token

@tesguest123 前端需要。跳转。刷新。清空表单等

从功能上来讲当然是前端的锅，就算后端验证，用户也会看到错误提示。

我以前做前端的时候，前端数据显示有问题，老大以为前端代码有问题，后来我一查，api 返回数据的问题。

对于重复提交的问题。
1 、前端点击按钮提交后，loading 改成 true, 按钮改成 loading 状态，此时点击按钮因为判断 loading 为 true 就不执行任何操作了。
2 、后端每个 api 请求可以加个 unique request id，靠这个判断是不是重复请求。

幂等和防抖都要做的。

前后都做是最好的 但是会增加不少工作量

非要甩锅就甩前端，毕竟对后端来说这只能算是流程优化，对前端来说已经算 bug 了(因重复提交导致的数据异常除外)。。。

目前来看，互联网所见的大部分服务都是前端做限制，毕竟前端限制简单粗暴快，只要前端做好后端基本不会受到重复数据了，只有 hacker 会破解前端来重复提交，不过对 hacker 来说做这种简单后端限制意义也不大

有些框架倒是自带了后端验证，但是个人不是很喜欢

@mirrorpen #8 请问一下，传统的后端使用模版渲染 html 可以把 csrf 嵌入到页面中，这是安全的， 前后端分离的时候应该怎么处理呢，使用 api 获取 key 吗，似乎并不安全

前端 20%，后端 80%

不是很清楚其他 UI 库，Ant Deisgn 按钮的 loading 属性为 true 的时候会自动拒绝响应 click 事件，前端开发者只需关心 loading 的状态即可

主要在于后端

前端改了就能完全保证不产生重复数据了吗？不能。后端修改完了呢？前端会是什么效果，重复点击的时候产生无用请求乃至抛错，所以也得改。

前端的主要负责对象是用户，最主要的责任给用户合理的暗示：

- 比如通过按钮失效来告诉用户点击成功了（不然用户会烦躁 “究竟点到了没”）
- 比如通过进度条（或转圈圈）来告诉用户正在处理中。

后端的主要负责对象是公司（公司数据的安全、服务器的稳定），最主要的责任是假设每一个请求都有可能是攻击。

你写前端节流不会么 这类情况我们都是前端做

主锅在后端。

因此，数据重复问题 100% 是后端的责任。

另外，用户点击按钮的 “使用体验”（能感觉到点击生效吗、能感觉到正在处理吗）则是前端的责任。

如果用户体验不好，烦躁地多次连击按钮，这个烦躁应该由前端负责解决，但后台数据是否重复这个前端是解决不了的（因为还有攻击者不走正常前端页面）。

注意，前端使按钮失效，说来说去都是为了让用户体验更好而已，**绝对不是** 为了让后端不接受重复提交的，因为这对于前端来说是一个不可能的任务，既然不可能，就没有责任。

@suke971219 前端向后端请求个 token，后端 token 放 redis 啥的，请求表单时做校验

如果在产品设计时就没有定义好，重复点击或重复提交表单该怎么处理，造成前后端撕逼，那就是产品经理的责任了

前后端都得做。

前端控制点击状态是为了避免双击或者网络不佳时有人多次点击。另外，每次进入这个页面的时候，前端最好生成一个 key，表单提交的时候带上 key，用于后端判断是否多次点击。（当前端判断请求失败 /允许再次请求的时候，前端才会刷新这个 key ）
同样的，对于响应速度一般的接口（尤其是插入，容易造成业务数据重复）后端要采用 用户-key-接口 为单元的锁。

前端做吧。

有没有人能说说前后端都分别怎么做最好？

上分布式锁

最极端的情况，前端只对提交成功做了回调，那么后端就需要把提交重复、提交写入失败、网络问题等等情况都要返回提交识别的状态码，这样就算前端不验证，数据也是安全的

@rekulas 不不，非要甩锅就甩后端，对前端来说只是用户体验不好，对后端来说这可是 CSRF 漏洞

不过我觉得最大的锅在产品和交互设计

@eason1874 不一定要清空，但是提交时禁止，并且有提交提示要的

说前端大部分责任的真是够了...

说到校验顺序，不是开发完成，联调，功能实现了，给产品看，产品确定完成度，然后交由测试做测试，看是否有隐藏的 bug 和不兼容的情况
另外 非要说问题，产品规划里这个说明咩有，前端自测，后端联调，都跑不了，毕竟所有相关的都没有考虑这个问题，然后交互是否设计了提交时的样式。。。

作为一个老司机 我可以明确的告拆你 这种事 就是谁能拍板 就听谁的 你们后端大佬说了算 那完全可以 让前端改,从技术实现上来说 前端好改 只要提交后加个 disable 就可以了, 当然有人说了 不行 你们后端也得加 对此 我做过多年的项目经验来讲认为 可以有 但没必要, 你看看 支付宝 微信 的接口会给你加这个吗，你重复调不也会产生重复数据。你让他们给你改试试

前端最好做，后端一定要做
前端做了也改变不了其他人调用你的接口出现这个问题，除非你打算让所有的前端包括客户端都做
后端做了一定能解决这个问题，哪怕前端一点都不做

前端后端都要做

避免重复提交，请使用幂等

肯定是后端的锅，前端只管提示，后端管处理

重复提交问题是后端的锅。
前端只负责提醒用户状态，不负责处理重复提交问题。

前端要做：尽量减少到后端的可能，一来是有效减低幂等问题的可能，二来在高 qps 场景下避免重复点击可以给服务端适当减负
后端要做：这 tm 本来就是你自己幂等的问题。你 tm 还不做？

后端的锅比较大

前端方案：按钮点击后禁用，response 回来了解禁
后端方案：csrf_token 需要放在 session 而非 cookie，并且用分布式锁确保 session 的读取和更新两步操作具有原子性
攻击方案：先抓取页面，获得 csrf_token，然后 post，无限循环
结论：前端解决重复提交的成本低，后端的 csrf_token 继续放 cookie，在防火墙级别封掉过大流量的 IP，然后禁用攻击者账户，清理垃圾数据

后端的锅，居然没做数据重复判断，php ？

后端必须做,

前端是交互问题, 比如 disable 什么的
哪怕前端不做, 后端也应该返回错误提示

@otakustay 额，csrf 表示不背这个锅。

幂等性设计
https://v2ex.com/t/693907?p=1#r_9307670
https://v2ex.com/t/701963?p=1#r_9427365
https://v2ex.com/t/701963?p=1#r_9428567

@leopod1995

你的 80%是怎么算的？

前端做是考虑用户体验，后端做是考虑数据安全。前后端各自基于不同的角度去考量，还能分出个后端 80%，前端 20%的占比来？

笑话！

后端做幂等，前端按钮控制

几乎是后端的锅，不用想，再怎么耍赖，也还是后端的锅.
前端也可以做验证，但也只是做得更好的体验而已，最终验证只能是后端呀.

前后端分离的项目，csrf token 应该不管用了， 因为前端前端生成表单时，是不需要请求后端 API 的

这个要看功能，有些功能是不需要防止重复提交的，但是有需要避免重复提交的，不管前端做没做，后端的锅，前端只是体验问题

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

前段防抖, 后端幂等

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

后端必须做，前端建议做

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

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

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

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

幂等

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

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

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

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

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

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

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

主要责任在后端。

前端 debounce 加 loading 和 disable 可以处理

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

看场景

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

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

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

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

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

责任是后端的，前端要做也是让交互更友好，如果直接走接口测试工具如 Postman 也会出现重复提交，这下和前端没关系了吧，所以责任一目了然。

我纸笔已经准备好了，谁能告诉我前端 20%，后端 80%怎么算的？

前端算开发事故，后端算业务事故。前端 20 大板，后端 80 大板。

@zsdroid 你怎么直到我要发贴[dog]，哈哈，用微积分算的行不行？哈哈。

@zaul 兄弟，到我们部门来吧，我们需要你~~~~

@tpsxiong 当然只能一个人占用啊，不验证重放并不是指不验证数据啊，我看楼上很多理解会影响了数据安全的，估计是误解重放和数据验证了，重放验证是第一层，数据验证是第二层，略过重放只会影响体验不会影响数据准确性

看看 v2 重复发两个相同内容的回复会发生什么~

应该是互不相信原则吧，前端肯定要做重复点击保护，后端也需要做相关保护吧，如果只有前端做保护，有人爆接口也没招

数据重复，后端背锅，数据库应加唯一约束。

一般这个时候我都会默默的加上，前端加不加我管不了。跟前端说又是一顿撕逼

都得做，对前端来说这叫交互，对后端来说这叫限流

前端最基本的要做表单提交的防抖！常识问题。 当然后端也要加

后端是兜底的，后端苦啊

都有责任，前端后端都要有验证机制

这个标题看得我：前端不算开发人员吗？

v2 就能重复发

如果是公开的网站肯定是后台的锅,如果内部网站肯定是前台的锅....内部网站不存在恶意攻击,前台用请求频率就可以判断是不是重复请求.

顺便问下，如果业务允许数据重复，后端该做些什么事？

@wysnylc 草泥马有一天要过河，就上了船。然后发现船一直没动，岸上的小伙伴大喊：草泥马，摆渡一下会死啊！

都重复数据了，主锅肯定在后端，前端重复提交只能算体验问题。