Одна форма создаёт несколько заявок: защита от повторных нажатий

Рассмотрим учебную форму запроса предложения. Пользователь нажал кнопку, ответ задержался, и он нажал ещё раз. Без явных состояний интерфейса непонятно, выполняется ли запрос. Если каждое нажатие создаёт отдельное обращение, отдел продаж получает несколько одинаковых записей, а посетитель всё равно не уверен, что его услышали.

Сначала воспроизведите один конкретный повтор

На учебной копии замедлите ответ и отправьте форму дважды. Запишите число сетевых запросов и число созданных тестовых обращений. Эти величины могут отличаться: один запрос может обрабатываться повторно на промежуточном слое, а два запроса могут уже объединяться сервером. Без наблюдения обеих границ причина остаётся неопределённой.

Проверяйте нажатие мышью, Enter в поле и отправку из мобильного интерфейса. Обработчик, привязанный только к клику по одной кнопке, может пропустить другой путь. Веб-форма имеет собственный механизм отправки; текущая документация MDN отдельно описывает событие submit и различие программных способов его вызова.

Убедитесь, что один пользовательский шаг не запускает два обработчика. Повторная инициализация модального окна иногда навешивает новый обработчик поверх старого. В таком случае даже единственное нажатие создаёт два запроса. Блокировка кнопки не исправляет двойную регистрацию событий и может лишь сделать дефект менее заметным.

Дайте форме понятные состояния

До отправки форма доступна для ввода. После успешной локальной проверки она переходит в состояние обработки: кнопка сообщает о действии, повторная отправка временно ограничена, а введённые значения сохранены. После ответа появляется подтверждение либо конкретная ошибка с возможностью исправить данные или повторить запрос.

Не выключайте форму до проверки обязательных полей. Пользователь должен получить ошибку неполного телефона или почты и продолжить ввод. Если интерфейс блокируется раньше, неуспешная валидация может оставить кнопку недоступной навсегда. Переход в обработку начинается только тогда, когда запрос действительно готов к отправке.

Индикатор должен иметь текстовое объяснение. Один вращающийся значок не сообщает, сохранена ли заявка и надо ли ждать. Подпись «Отправляем запрос» описывает действие. После успеха нужна ясная формулировка принятия обращения в пределах фактически подтверждённого результата, без обещаний немедленного звонка, если такого правила нет.

Почему блокировки кнопки недостаточно

Браузерная защита действует только в текущем интерфейсе. Запрос можно повторить после обновления страницы, через вторую вкладку или из-за поведения сетевого посредника. Кроме того, сервер мог создать обращение, но ответ не дошёл до браузера. Для посетителя это выглядит как ошибка, хотя повтор без защиты создаст ещё одну запись.

Поэтому на сервере полезен договор о повторе одного логического обращения. Клиент получает или создаёт идентификатор попытки по правилам проекта и сохраняет его при повторе того же запроса. Сервер связывает этот ключ с результатом. Повтор с тем же содержимым возвращает согласованный результат, а не создаёт вторую сущность.

Название заголовка или поля не выбирают в статье как универсальный стандарт. Оно зависит от существующего API. Существенны свойства: ключ относится к одной операции, сервер хранит достаточное состояние для повтора, а две одновременные обработки не могут обе принять решение «записи ещё нет» и создать дубли.

Идемпотентность и поиск похожих контактов решают разные задачи

Поиск одинакового телефона в CRM не заменяет защиту одной отправки. Один человек может законно обратиться по двум разным товарам. Если объединять всё только по контакту за произвольное время, новая потребность потеряется. Защита от повтора должна отличать повтор того же обращения от нового осмысленного запроса.

В учебном примере первая заявка касается конфигурации А, вторая конфигурации Б. Одинаковый контакт не делает их дублями автоматически. А два запроса по конфигурации А с одним ключом отправки должны обрабатываться как одна операция в согласованном контракте. Это различие записывают до реализации, чтобы разработчик не подменил бизнес-правило удобной эвристикой.

Если CRM сама выполняет объединение контактов, сохраните эту функцию отдельно. Она отвечает за структуру клиентской базы, а не за число заявок. В отчёте приёмки нужно считать именно обращения нужного типа, не только количество новых контактов: контакт может быть один, а дубли сделок останутся.

Потерянный ответ требует осторожного сообщения

Таймаут браузера не доказывает, что CRM не создала запись. Не пишите «Заявка не отправлена» без такого подтверждения. Лучше сообщить, что подтверждение пока не получено, и предложить безопасный повтор, если API его поддерживает. Текст ошибки должен соответствовать наблюдаемой границе, а не предположению интерфейса.

При повторе сохраняют ключ и исходные данные одной операции. Если пользователь изменил товар или состав конфигурации, это уже другой запрос, и правило повторного использования ключа нужно пересмотреть. Сервер должен обнаруживать конфликт одного ключа с разным содержимым, а не случайно возвращать результат другой заявки.

Срок хранения результата повтора выбирают по реальному сценарию. Слишком короткий срок оставляет риск дублей после возвращения на страницу; бесконечное хранение без очистки создаёт ненужные данные. В статье не задаётся универсальный срок: его согласуют с жизненным циклом формы и существующей инфраструктурой.

Разблокировка после ошибки

После подтверждённой ошибки валидации пользователь должен исправить поле без потери остальных данных. После временного сбоя должна быть понятная возможность повторить. После успеха интерфейс не должен сохранять активную кнопку с прежним текстом так, будто ничего не произошло. Каждое завершение возвращает форму в определённое состояние.

Обработайте закрытие и повторное открытие модального окна. Закрытое окно не означает отмену серверной операции. Если запрос продолжает выполняться, новое окно должно учитывать это состояние или создавать новую независимую форму по ясному правилу. Не разрешайте случайно запустить прежнюю отправку повторно только потому, что DOM был создан заново.

При сетевом разрыве сохраняйте данные в пределах разрешённого жизненного цикла. Нельзя ради удобства бессрочно писать контакты в публично доступное хранилище или журналировать полный запрос. Учебная приёмка использует синтетические контакты, а политика хранения рабочих обращений определяется отдельно.

Как проверить два одновременных запроса

Последовательный повтор недостаточен для проверки серверной защиты. Два одинаковых запроса могут прийти почти одновременно и оба пройти проверку отсутствия записи. На стенде отправьте их параллельно с одним ключом. Ожидайте один согласованный результат и отсутствие двух созданий, а не просто отсутствие ошибки сервера.

Проверьте сбой между созданием записи CRM и сохранением служебного результата. Этот промежуток особенно сложен, если системы не участвуют в одной транзакции. Реализация должна иметь способ восстановить состояние или найти уже созданную запись по безопасной корреляции. Публичное руководство объясняет риск; конкретный механизм выбирают после изучения API и существующего обмена.

Отдельный отрицательный тест использует один ключ с изменённым содержимым. Сервер не должен молча выдавать успех по прежней операции. Нужен согласованный ответ о конфликте или другая явная политика, которая не теряет новое сообщение пользователя. Проверка только одинаковых повторов этот дефект не обнаружит.

Приёмка в интерфейсе и CRM

Подготовьте обычный успешный запуск, двойной клик, Enter, медленный ответ, ошибку поля, временный сетевой разрыв и повторное открытие окна. Для каждого заранее запишите ожидаемые состояния кнопки и число обращений. Сравнивайте результат после завершения обработки, а не сразу после исчезновения индикатора.

Проверьте клавиатурный фокус и чтение статуса вспомогательными технологиями. Пользователь должен понимать, где находится ошибка и что изменилось после отправки. Заблокированная кнопка без доступного сообщения оставляет часть посетителей без обратной связи, даже если дубли технически устранены.

Принятый сценарий даёт понятный ответ человеку и устойчивое число записей системе. В документации зафиксируйте границы гарантии: какие формы подключены, как определяется одна операция и какие повторы безопасны. Не называйте решение полной защитой от спама или любых дублей CRM, если проверена только повторная отправка одной формы.

Как отличить новую заявку от исправления прежней

После ошибки ввода пользователь может изменить номер телефона и повторить отправку. Если прежняя операция ещё не была принята, это продолжение заполнения формы. Если обращение уже создано, изменение данных требует другого правила: дополнение существующей записи или новое обращение. Интерфейс не должен решать это только по наличию прежнего ключа в памяти.

В договоре API полезно явно разделить неподтверждённую попытку и принятую операцию. Ключ создают в момент, соответствующий выбранному жизненному циклу. Если содержимое поменялось после принятия, сервер не должен игнорировать исправление под видом успешного повтора. Такой сценарий нужно включить в приёмку рядом с двойным кликом.

Обновление страницы создаёт ещё один вопрос: сохранять ли незавершённую попытку между загрузками. Решение зависит от формы и политики хранения. Для простой публичной заявки можно ограничиться безопасным повтором в текущем окне, честно описав границу гарантии. Для сложного конфигуратора может потребоваться сохранённый черновик, но это отдельная функция, а не обязательное следствие блокировки кнопки.

Как диагностировать дубли без просмотра чужих обращений

Учебные записи должны содержать различимый тестовый признак в разрешённом поле, чтобы их можно было найти и посчитать. Не используйте телефоны и почту настоящих покупателей. Достаточно синтетических данных и списка времени запусков. Проверка количества заявок тогда воспроизводима и не требует открывать рабочую переписку.

При анализе журнала фиксируйте связь между пользовательским действием, сетевой попыткой и созданной сущностью. Один общий текст «запрос отправлен» не объясняет, на какой границе появился дубль. Нужны разные технические события с общей корреляцией, но без полного содержимого контактных полей.

Если дубль возникает только на определённой странице, сравните подключённые обработчики и жизненный цикл виджета. Иногда общая библиотека работает правильно, а старый встроенный скрипт страницы создаёт второй путь. Исправление должно удалить или перенаправить этот путь, сохранив единую точку отправки. Дополнительная задержка перед кликом не устраняет причину.

Что не входит в эту защиту

Безопасный повтор одной операции не служит полноценной антиспам-системой и не объединяет обращения из разных каналов. Ограничение частоты, проверка злоупотреблений и правила CRM-дублей решаются отдельно. Их можно согласовать в общей архитектуре, но нельзя объявлять выполненными только потому, что двойной клик перестал создавать две записи.

Успешный тест должен включать ожидание окончательного серверного результата. Немедленное закрытие окна не доказывает отсутствия второй операции, которая ещё выполняется в фоне. Считайте созданные учебные обращения после завершения обеих попыток и сопоставляйте их с одной логической отправкой.

Связанные разборы

Для смежных решений пригодятся материалы: Интеграция сайта с Битрикс 24: формы, заявки, лиды и контроль источников. При развитии формы отдельно проверяйте её передачу в CRM. Исправление двойного клика не заменяет подтверждение серверного приёма и обработку повтора запроса.

Вопросы по теме

Достаточно ли отключить кнопку после клика?

Нет. Это ограничивает случайные нажатия в одном интерфейсе, но не повтор запроса после потери ответа или из другой вкладки.

Можно ли объединять все обращения по одному телефону?

Не как замену защите отправки. Один контакт может отправить разные законные запросы; правило должно различать повтор операции и новое обращение.

Документация и источники

• MDN: событие submit: Различие способов отправки формы и встроенной проверки.
• MDN: проверка веб-форм: Клиентская проверка не заменяет серверную.