Ошибка доступа экстранет-пользователя к /index.php

Сообщение обычно выглядит примерно так:

Доступ запрещён. Просмотр файла /index.php запрещён.

На первый взгляд кажется, что проблема именно в файле /index.php. Но чаще это симптом: пользователь оказался на странице, где его группы не имеют права чтения.

Для экстранета это особенно важно. В коробке экстранет может быть настроен как отдельный сайт, а основной интранет и экстранет могут иметь разные корневые разделы, шаблоны, группы доступа и правила в .access.php.

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

Другой вариант — пользователь действительно находится на сайте экстранета, но у его группы нет права чтения на корень сайта или конкретный index.php. Это может появиться после ручной правки прав, переноса портала, изменения групп или неудачной настройки экстранет-сайта.

Поэтому сначала нужно разделить две ситуации: пользователь идёт на неправильный сайт или права сломаны на правильном сайте.

Сначала стоит посмотреть, в каких группах состоит проблемный пользователь:

const USER_ID = 123;

$user_groups = CUser::GetUserGroup(USER_ID);

echo '<pre>';
print_r($user_groups);
echo '</pre>';

Потом удобно вывести список групп и найти, какая из них отвечает за экстранет:

$group_result = CGroup::GetList(
    'id',
    'asc',
    [
        'ACTIVE' => 'Y',
    ]
);

while ($group = $group_result->Fetch()) {
    echo '<pre>';
    print_r([
        'ID' => $group['ID'],
        'NAME' => $group['NAME'],
        'STRING_ID' => $group['STRING_ID'],
    ]);
    echo '</pre>';
}

На разных коробках ID групп отличаются. Поэтому в примерах ниже G16 — не универсальное значение, а условный ID группы, которой нужно дать доступ. На реальном портале его надо заменить на ID вашей группы экстранет-пользователей.

Если пользователь вообще не состоит в нужной экстранет-группе, исправлять .access.php бессмысленно. Сначала нужно привести в порядок группы пользователя, а уже потом права раздела.

Упрощённо правило может выглядеть так:

$PERM["/"]["*"] = "D";
$PERM["/"]["2"] = "R";

Здесь для всех стоит запрет, а для группы с ID 2 разрешено чтение. Если экстранет-пользователь не входит в группу, которой разрешено чтение, он получит ошибку доступа.

Право может быть задано не только на корень, но и на конкретный файл:

$PERM["index.php"]["*"] = "D";
$PERM["index.php"]["G11"] = "R";

Посмотреть текущий файл прав можно временным административным скриптом:

$access_file = $_SERVER['DOCUMENT_ROOT'] . '/.access.php';

if (is_file($access_file)) {
    echo '<pre>';
    echo htmlspecialchars(file_get_contents($access_file));
    echo '</pre>';
}

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

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

Если пользователь находится на правильном экстранет-сайте, но доступ к главной закрыт, нужно дать чтение именно группе экстранета:

$PERM["index.php"]["*"] = "D";
$PERM["index.php"]["G16"] = "R";

А вот так делать обычно неправильно:

$PERM["index.php"]["*"] = "D";
$PERM["index.php"]["1"] = "R";

В этом примере чтение дано только администраторам. Экстранет-пользователь в такую группу не входит, поэтому проблема для него останется.

Не стоит решать ошибку грубым открытием /index.php для всех. Если дать чтение группе Все пользователи или неавторизованным посетителям без понимания последствий, можно открыть лишние разделы. Для экстранета лучше выдавать доступ конкретной группе внешних пользователей и только к тем разделам, которые им действительно нужны.

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