Налаштування підтвердження реєстрації через email 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Пропоновані послуги
Показано 1 з 1 послугУсі 1626 послуг
Налаштування підтвердження реєстрації через email 1С-Бітрікс
Проста
~1 робочий день
Часті питання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989

Налаштування підтвердження реєстрації через email 1С-Бітрікс

Стандартна реєстрація в 1С-Бітрікс за замовчуванням або не вимагає підтвердження email, або використовує штатний механізм — залежно від налаштувань компонента system.auth.registration. Проблема в тому, що лист підтвердження надсилається через CEvent::Send() із шаблоном NEW_USER_CONFIRM, який виглядає як системне повідомлення 2005 року. Переробка цього механізму під сучасні вимоги — транзакційний email, брендований шаблон, правильна обробка повторних запитів — потребує втручання в кілька точок системи.

Як працює стандартний механізм

При реєстрації з увімкненим параметром EMAIL_CONFIRMATION компонент system.auth.registration створює користувача з ACTIVE = N і надсилає лист через подію NEW_USER_CONFIRM. Лист містить посилання вигляду:

/bitrix/[email protected]&checkword=HASH

При переході за посиланням скрипт confirm.php перевіряє CHECKWORD із таблиці b_user і активує акаунт (ACTIVE = Y).

CHECKWORD зберігається прямо в b_user.CHECKWORD — одне поле на все. Якщо користувач запросив повторний лист, старий CHECKWORD перезаписується.

Кастомний шаблон листа

Шаблон листа редагується в Налаштування → Поштові події → NEW_USER_CONFIRM. Для брендованого HTML-листа:

  1. Створюємо шаблон типу NEW_USER_CONFIRM із повним HTML-тілом
  2. Використовуємо змінні: #EMAIL#, #LOGIN#, #NAME#, #CONFIRM_CODE#, #SITE_URL#
  3. Для правильного рендеру HTML у поштових клієнтах — table-based верстка, інлайн-стилі

Якщо потрібен транзакційний провайдер (SendGrid, Mailgun, Postmark) замість PHP mail() — підключаємо через модуль main. Встановлення кастомного обробника відправки:

// В init.php або модулі
AddEventHandler('main', 'OnBeforeEventSend', function(array &$eventFields, array &$message, array $siteData) {
    if ($message['EVENT_NAME'] === 'NEW_USER_CONFIRM') {
        // Перехоплюємо та надсилаємо через SendGrid API
        SendGridMailer::send(
            to: $eventFields['EMAIL'],
            subject: $message['SUBJECT'],
            html: $message['BODY']
        );
        return false; // Скасовуємо стандартну відправку
    }
});

Повторна відправка листа

Стандартний компонент не надає кнопку «Надіслати повторно». Додаємо:

// /local/components/local/auth.resend-confirm/class.php
if ($_POST['resend_email'] ?? false) {
    $email = trim($_POST['email'] ?? '');

    $user = \Bitrix\Main\UserTable::getList([
        'filter' => ['EMAIL' => $email, 'ACTIVE' => 'N'],
        'select' => ['ID', 'LOGIN', 'NAME', 'CHECKWORD', 'CHECKWORD_TIME'],
        'limit'  => 1,
    ])->fetch();

    if (!$user) {
        $this->addError('Користувача не знайдено або вже активовано');
        return;
    }

    // Rate limit: не більше 1 листа за 5 хвилин
    $lastSent = strtotime($user['CHECKWORD_TIME']);
    if (time() - $lastSent < 300) {
        $this->addError('Лист вже надіслано. Зачекайте 5 хвилин.');
        return;
    }

    // Генеруємо новий checkword
    $newCheckword = md5(uniqid('', true));
    \CUser::Update($user['ID'], ['CHECKWORD' => $newCheckword]);

    \CEvent::Send('NEW_USER_CONFIRM', SITE_ID, [
        'EMAIL'        => $email,
        'LOGIN'        => $user['LOGIN'],
        'NAME'         => $user['NAME'],
        'CONFIRM_CODE' => $newCheckword,
        'SITE_URL'     => SITE_SERVER_NAME,
    ]);

    $this->result['SUCCESS'] = true;
}

Термін дії посилання

За замовчуванням CHECKWORD не має терміну дії — посилання з місячної давності листа все одно спрацює. Щоб обмежити термін:

В обробнику confirm.php (або перевизначеному компоненті підтвердження) перевіряємо CHECKWORD_TIME:

$user = \Bitrix\Main\UserTable::getList([
    'filter' => ['LOGIN' => $login, 'CHECKWORD' => $hash, 'ACTIVE' => 'N'],
    'select' => ['ID', 'CHECKWORD_TIME'],
])->fetch();

if (!$user) {
    ShowError('Посилання недійсне');
    return;
}

$checkwordAge = time() - strtotime($user['CHECKWORD_TIME']);
if ($checkwordAge > 86400 * 3) { // 3 дні
    ShowError('Термін дії посилання вичерпано. <a href="/resend-confirm/">Запросити новий лист</a>');
    return;
}

\CUser::Confirm($login, $hash);

Автовидалення неактивованих акаунтів

Користувачі, що не підтвердили email за N днів, засмічують базу. Агент раз на добу видаляє їх:

function DeleteUnconfirmedUsers(): string
{
    $cutoffDate = (new \DateTime())->modify('-7 days')->format('Y-m-d H:i:s');

    $res = \Bitrix\Main\UserTable::getList([
        'filter' => ['ACTIVE' => 'N', '<DATE_REGISTER' => $cutoffDate],
        'select' => ['ID'],
    ]);

    while ($row = $res->fetch()) {
        \CUser::Delete($row['ID']);
    }

    return __FUNCTION__ . '();';
}

Реєструємо агент у модулі через \Bitrix\Main\Agent.

Склад робіт

  • Кастомний HTML-шаблон листа NEW_USER_CONFIRM
  • Підключення транзакційного провайдера (опціонально)
  • Компонент повторної відправки з rate limit
  • Обмеження терміну дії посилання підтвердження
  • Агент автовидалення неактивованих акаунтів

Терміни: 3–5 днів для базової переробки з кастомним шаблоном і повторною відправкою. 1–1.5 тижні при підключенні транзакційного провайдера та повній переробці UX.