Сценарії, канали, таймінги й ліміти

14. OTP - підтвердження телефону#

OTP - це одноразовий код, який клієнт отримує на телефон і вводить на сайті.

Збільшити ↗

Як увімкнути OTP#

1. Спочатку перевірте SMS або дзвінок.
2. Відкрийте OTP -> Налаштування OTP.
3. Увімкніть OTP Статус.
4. Увімкніть тільки потрібні сценарії OTP.
5. У полі Канал надсилання OTP виберіть, через що модуль має спробувати відправити OTP-код першим: SMS, Viber або Telegram. Якщо увімкнена Авторизація дзвінком, цей блок показується як Канал OTP без дзвінка: першим буде дзвінок, а вибраний канал працює тільки для OTP без дзвінка.
6. Налаштуйте довжину коду і часи.
7. Перевірте маршрути сторінок, якщо оформлення замовлення нестандартне.
8. Натисніть Зберегти.
9. Протестуйте на сайті як клієнт.

Сценарії OTP#

Як OTP працює для клієнта#

1. Клієнт вводить телефон.
2. Модуль перевіряє формат номера, країну, IP, браузер, сесію і ліміти.
3. Якщо все нормально, модуль вибирає сценарій доставки OTP.
4. Якщо увімкнена авторизація дзвінком і вибраний шлюз її підтримує, модуль спочатку запускає дзвінок.
5. Якщо дзвінок не використовується, модуль створює OTP-код і відправляє його через канал, вибраний у полі Канал надсилання OTP.
6. Якщо дзвінок не вдався і ввімкнене резервне SMS для дзвінка, модуль створює OTP-код і надсилає його саме через SMS.
7. Клієнт вводить код або підтверджує дію через дзвінок.
8. Модуль перевіряє код, результат дзвінка і термін дії підтвердження.
9. Якщо перевірка успішна, номер вважається підтвердженим.

Якщо будь-яка перевірка не пройдена, код або дзвінок не запускається. Це зроблено спеціально, щоб не витрачати баланс на ботів і підозрілі запити.

Повторне використання підтвердження та явний вихід#

Після успішного OTP той самий номер у цьому браузері можна повторно використовувати для входу, реєстрації та оформлення замовлення протягом значення Час життя підтвердженого номера. Звичайні переходи між сторінками, виправлення полів форми та створення кількох окремих замовлень не вимагають нового коду, поки строк довіри не завершився і номер не змінився.

Явне натискання Вийти є безпековою межею. Модуль одразу видаляє серверний стан підтвердження, незавершені дозволи оформлення та cookies телефонного входу. Навіть якщо налаштований строк довіри ще не завершився, наступний вхід за номером телефону вимагатиме новий OTP. Це захищає акаунт на спільному або переданому іншій людині пристрої. Ідентифікатор браузера для антиспам-захисту при цьому зберігається: вихід не повинен обнуляти ліміти чи приховувати підозрілу активність.

Логіка вибору каналу OTP#

Для OTP є окреме поле Канал надсилання OTP. Воно не залежить від каналу звичайних повідомлень адміну, статусів замовлення, відкладених подій або масової розсилки.

Якщо ввімкнена Авторизація дзвінком, адмінка одразу змінює цей блок на Канал OTP без дзвінка. Це не декоративна назва, а захист від плутанини: поле не керує першим дзвінком або резервним SMS після його помилки.

Основна логіка така:

1. Дзвінок має пріоритет, якщо ввімкнена Авторизація дзвінком, модуль і OTP увімкнені, а вибраний Call gateway підтримує потрібний сценарій. Це може бути SMS-шлюз із підтримкою дзвінків або окремий Stream Telecom.
2. Резервне SMS після дзвінка спрацьовує, якщо дзвінок не запустився або не підтвердився, поле SMS при помилці дзвінка ввімкнене і налаштований основний SMS-шлюз. У цьому випадку модуль надсилає OTP саме через SMS, а не через канал, вибраний у полі Канал надсилання OTP / Канал OTP без дзвінка.
3. Якщо дзвінок не використовується, перша спроба OTP іде через вибраний канал: SMS, Viber або Telegram.
4. Якщо вибраний канал не спрацював, модуль перевіряє інші доступні й увімкнені канали в порядку Telegram -> Viber -> SMS, пропускаючи вже вибраний канал.
5. Якщо інших доступних каналів немає або резервне надсилання для них вимкнене, додаткової спроби не буде.

Приклади:

Важливо: якщо у списку вибору є тільки SMS, то після невдалого надсилання SMS запасного каналу не буде. Якщо вибрано Без SMS / тільки авторизація дзвінком, а SMS-шлюз не налаштований, резервне SMS для OTP недоступне.

Як працює резервне надсилання для OTP#

Приклад: якщо увімкнений дзвінок, підключений Telegram і налаштований SMS-шлюз, OTP спочатку піде через дзвінок. Якщо дзвінок провалиться і SMS при помилці дзвінка увімкнене, модуль відправить код через SMS, а не через Telegram або Viber. Якщо вибрано Без SMS / тільки авторизація дзвінком, після невдалого дзвінка SMS не піде.

Якщо дзвінок вимкнений і в Канал надсилання OTP вибрано SMS, модуль спочатку відправить SMS. Якщо SMS не спрацює, він не буде повторювати SMS, а перевірить тільки інші доступні канали: Telegram і Viber. Якщо вони не підключені, додаткової спроби не буде.

Які сценарії вмикати#

Код і таймінги#

Ліміти повторного надсилання#

Ліміти помилкових кодів#

Маршрути сторінок#

Стандартні сторінки OpenCart модуль підключає автоматично:

• account/register;
• account/edit;
• checkout/checkout.

Якщо у вас Simple, One Page Checkout або інший нестандартний модуль оформлення замовлення, OTP може не з'явитися автоматично. Тоді потрібно додати маршрут сторінки до блоку додаткових сторінок.

Для звичайного користувача правило просте: якщо OTP на оформлення замовлення не з'явився, передайте цей пункт розробнику.

Шаблон для розробника:

У модулі SAP - SMS / OTP Pro увімкнений OTP для оформлення замовлення, але на оформлення замовлення поле підтвердження не з'являється.
Потрібно перевірити маршрут сторінки оформлення замовлення і додати його в "Додаткові сторінки перевірки телефону" або "Сторінки сторонніх модулів".

Захищене оформлення замовлення та правила ризику#

Збільшити ↗

Функція Ризикові замовлення захищає створення замовлення на сервері, а не лише показує вікно OTP у браузері. Вона підтримує три рівні захисту: рекомендований збалансований, суворий для кожного замовлення та вибірковий за власними правилами.

Вкладка OTP -> Ризикові замовлення показується одразу після ввімкнення сценарію OTP -> Налаштування OTP -> Оформлення замовлення. Якщо цей сценарій вимкнути, вкладка ховається, а перевірка правил не виконується.

Логіка роботи:

• Оформлення замовлення увімкнено, а Підтвердження ризикових замовлень вимкнено - оформлення вимагає підтверджений номер, але чинне підтвердження повторно використовується протягом заданого часу життя;
• обидва перемикачі увімкнено, режим Тестовий - у журналі фіксуються випадки, які в робочому режимі вимагали б OTP, але оформлення не зупиняється;
• у робочому збалансованому режимі чинне підтвердження потрібне гостю, новому клієнту та для непідтвердженого номера; перевірений постійний клієнт проходить без повторного коду, якщо не спрацювало власне правило;
• у робочому суворому режимі перевіряється кожне замовлення, але чинне підтвердження того самого номера повторно використовується до завершення його строку життя;
• у робочому режимі Лише правила чинне підтвердження потрібне тільки після збігу першого активного правила;
• новий OTP надсилається лише коли номер ще не підтверджений, строк довіри завершився, номер змінився або серверна сесія більше не підтверджує цей номер;
• для кожного окремого замовлення модуль створює новий correlation_id і окремий внутрішній дозвіл. Навіть коли використано чинне підтвердження без нового коду, дозвіл атомарно споживається фінальним створенням замовлення й не може бути повторно використаний паралельним запитом;
• миттєвий повтор фінального запиту з тим самим відбитком оформлення блокується як можливий дубль. Окреме наступне замовлення з новим станом checkout отримує власний дозвіл;
• строк внутрішнього дозволу не може перевищувати ані Час життя підтвердженого номера, ані Строк підтвердження checkout.

Безпечне ввімкнення#

1. Переконайтеся, що OTP Статус і Оформлення замовлення увімкнені.
2. Відкрийте OTP -> Ризикові замовлення.
3. Увімкніть перемикач у блоці Підтвердження ризикових замовлень.
4. Залиште Режим роботи = Тестовий - лише журнал.
5. Виберіть Рівень захисту = Збалансований.
6. Для поля Якщо OTP неможливо надіслати залиште блокування.
7. Задайте строк підтвердження оформлення замовлення.
8. Виберіть статуси замовлень, які магазин вважає успішними.
9. Створіть додаткові правила й натисніть Зберегти.
10. Перевірте гостя, нового клієнта, постійного клієнта та хоча б одне власне правило.
11. Перевірте блок Останні спрацювання.
12. Лише після перевірки журналу перемкніть режим на Робочий - вимагати OTP.

Основні налаштування#

Матриця рівнів захисту#

У тестовому режимі жоден із рівнів не зупиняє покупця. Журнал показує випадки, які вимагали б OTP після переходу в робочий режим.

Як перевіряються правила#

Кожне правило має назву, перемикач Активне правило, пріоритет, логіку умов і одну або кілька умов.

• Менше число в полі Пріоритет перевіряється раніше. Наприклад, 10 має вищий пріоритет за 20.
• Усі умови (AND) означає, що мають виконатися всі умови правила.
• Будь-яка умова (OR) означає, що достатньо хоча б однієї умови.
• Після першого збігу перевірка зупиняється. Саме назва цього правила потрапляє в журнал.
• Неактивне правило не впливає на оформлення замовлення.
• Кнопка копіювання створює копію правила, а червона кнопка видаляє його. Окрема червона кнопка в рядку умови видаляє тільки цю умову.

Показники правил#

Тип покупця читається так:

• Гість - покупець не авторизований;
• Авторизований клієнт - покупець авторизований і має хоча б одне замовлення в обраних успішних статусах;
• Клієнт без успішних замовлень - покупець авторизований, але ще не має замовлень у цих статусах.

Список для показника Спосіб оплати не зашитий у модуль. Він автоматично читає встановлені платіжні розширення та їхні статуси. Для OpenCart/ocStore 2.3 перевіряються старі ключі налаштувань, а для 3.x - нові ключі payment_*, із сумісною перевіркою в обидва боки. Якщо спосіб оплати встановлено, але він не з'явився у правилі, спочатку переконайтеся, що його статус справді Увімкнено, а потім перезбережіть сторінку модуля.

Рекомендований стартовий набір#

Пороги нижче - приклад, а не універсальна істина. Суми треба адаптувати до середнього чека й валюти магазину.

Тримайте правила від вузьких до загальних. Правило масових повторів має бути вище за правило великої суми, інакше журнал показуватиме тільки загальне правило, а причина ризику буде менш зрозумілою.

Останні спрацювання#

Журнал показує дату, назву правила, замаскований телефон, статус рішення та ID створеного замовлення, якщо воно вже існує. Відкритий номер у журналі ризику не зберігається.

Типові статуси журналу: збіг у тестовому режимі, потрібне підтвердження OTP, OTP підтверджено, чинне підтвердження використано повторно, замовлення створено, дозволено постійному клієнту, дозволено через відсутність збігу у вибірковому режимі або надсилання OTP не вдалося. У режимі приватності для адміністратора без головних прав телефон у цьому журналі маскується повністю.

Активні правила кешуються між запитами, а дані оформлення обчислюються тільки коли вони реально потрібні. Для гостя у збалансованому режимі та для будь-якого покупця в суворому модуль одразу знає, що потрібне чинне підтвердження номера, тому не читає власні правила з бази й не запускає їхні додаткові запити. Якщо підтвердження ще діє, окремий дозвіл створюється без надсилання нового OTP. Для перевіреного постійного клієнта правила все одно виконуються. Це зменшує навантаження без послаблення захисту.

17. OTP - тексти повідомлень#

Збільшити ↗

У цій вкладці налаштовуються тексти OTP-повідомлень.

Як налаштувати#

1. Відкрийте OTP -> Повідомлення OTP.
2. Перевірте текст для входу, реєстрації, профілю і оформлення замовлення.
3. Переконайтеся, що в тексті є {otp}.
4. Натисніть Зберегти.
5. Протестуйте кожний увімкнений сценарій.

Головне правило#

У повідомленні обов'язково має бути шорткод {otp}. Саме він підставляє код.

Нормальні приклади:

Код підтвердження: {otp}

Ваш код для підтвердження телефону: {otp}. Магазин Example.

Не робіть OTP-повідомлення довгим. Клієнт має швидко побачити код.