Перейти к содержимому
BXWiki

Оформление заказа требует авторизации - разбор причин

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

С чего начать

Запрашиваем страницу оформления без кук:

Окно терминала
curl -sS -b '' -o /tmp/checkout.html -w 'код ответа %{http_code}\n' \
     https://example.ru/personal/order/make/
grep -c 'sale.order.ajax' /tmp/checkout.html            # разметка формы заказа
grep -c 'system.auth.form' /tmp/checkout.html           # форма входа вместо неё

Эта проверка делит причины пополам. Разметка компонента в ответе означает, что гостя разворачивает сама форма заказа, а ответ без неё уводит разбор к правам группы и прологу страницы.

Смотрим гостя и настройки регистрации:

global $USER;
printf("вошёл: %s, группы: %s\n", $USER->IsAuthorized() ? 'да' : 'нет',
    implode(',', $USER->GetUserGroupArray()));
echo COption::GetOptionString('main', 'new_user_registration', 'N'), "\n";
echo COption::GetOptionString('main', 'new_user_registration_email_confirmation', 'N'), "\n";
// автоматическая регистрация при заказе опирается на обе эти настройки сразу

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

Читаем файловые права каталога оформления:

Окно терминала
find /home/bitrix/www/personal -name '.access.php' \
     -exec sh -c 'echo "== $1"; cat "$1"' _ {} \;
# уровень D закрывает страницу группе, R открывает её на чтение
# файл прав читается в прологе, до подключения компонента оформления

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

Перечисляем обязательные свойства типа плательщика:

$props = CSaleOrderProps::GetList([], ['PERSON_TYPE_ID' => 1, 'ACTIVE' => 'Y']);
while ($p = $props->Fetch()) {
    printf("%-18s тип=%-10s обязательно=%s\n",
        $p['CODE'], $p['TYPE'], $p['REQUIED']);   // поле пишется без буквы R
}

Обязательность проверяется на сервере и без значения заказ не пропускает. Профиль покупателя появляется только после первого оформленного заказа, поэтому поле, заполняемое из профиля, гостю взять неоткуда.

Причины

  1. Самостоятельная регистрация запрещена настройкой главного модуля примерно 28% случаев

    ПризнакАвтоматическая регистрация в компоненте включена, а гость всё равно видит форму входа.

    ПроверкаСмотрим в настройках главного модуля разрешение регистрации и запрос подтверждения по почте.

    Что делатьРазрешаем самостоятельную регистрацию и снимаем подтверждение по почте на время проверки оформления.

  2. В компоненте не включён заказ без учётной записи примерно 22% случаев

    ПризнакФорма входа рисуется прямо внутри оформления, отдельной страницей она не открывается.

    ПроверкаОткрываем параметры компонента оформления и ищем разрешение заказа с автоматической регистрацией.

    Что делатьВключаем автоматическую регистрацию и сверяем, что правится компонент именно этой страницы.

  3. Группе неавторизованных закрыт доступ к странице оформления примерно 18% случаев

    ПризнакВместо полей заказа отдаётся форма входа целиком, а шапка и подвал сайта на месте.

    ПроверкаЧитаем файл .access.php в каталоге оформления и во всех родительских папках.

    Что делатьСтавим группе уровень чтения на каталог оформления либо убираем лишнюю строку запрета.

  4. Обязательное свойство заполняется только из профиля покупателя примерно 14% случаев

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

    ПроверкаПеречисляем свойства типа плательщика и смотрим у них признак обязательности заполнения.

    Что делатьСнимаем обязательность у поля, которое гость заполнить не может, либо задаём значение по умолчанию.

  5. Свой обработчик или префильтр разворачивает гостя примерно 10% случаев

    ПризнакНа штатном шаблоне компонента картина та же, и ошибок в журнале веб-сервера нет.

    ПроверкаИщем в своём коде проверку входа с редиректом и фильтр Authentication у контроллера.

    Что делатьОставляем проверку там, где она нужна по задаче, и снимаем её со страницы оформления.

  6. Корзина гостя уезжает к другой учётной записи примерно 8% случаев

    ПризнакПосле автоматического входа корзина пустеет, и оформление снова просит войти на сайт.

    ПроверкаСравниваем идентификатор покупателя до входа и сразу после автоматической регистрации.

    Что делатьУбираем из своего обработчика входа пересоздание сессии и чистку куки покупателя.

Если ничего не помогло

Ищем свои проверки входа по коду проекта:

Окно терминала
grep -rn 'IsAuthorized\|LocalRedirect\|Authentication::class' \
     /home/bitrix/www/local/php_interface/ /home/bitrix/www/local/modules/
# редирект из пролога срабатывает раньше любого компонента страницы

Обработчик пролога отрабатывает до вывода страницы, поэтому его редирект неотличим от запрета по правам. Отличает их одно: права видны в файле, а редирект - только в коде.

Частые вопросы

Почему требует авторизацию при оформлении заказа, хотя автоматическая регистрация включена?

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

Как настроить оформление заказа без предварительной регистрации?

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

Как убрать обязательность полей при регистрации в оформлении?

Снять признак обязательности у свойства заказа в настройках модуля продаж. Символьный код свойства при этом часто не совпадает с именем поля в шаблоне, и сверять надо именно код.

После автоматической регистрации пропал заказ и открылась пустая корзина. Почему?

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

Оформление сломалось для гостей после обновления. Куда смотреть?

В журнал ошибок PHP: обновление модуля продаж иногда ломает ветку кода для неавторизованных. Лечится доустановкой свежих обновлений, а не правкой шаблона.

Смежное

Первоисточник