При разработке интеграций между базами 1С часто возникает задача ограничить доступ к веб-сервису не только на уровне логина и пароля, но и на уровне бизнес-логики. Например, если пользователю запрещен вход в определенное время или его учетная запись временно заблокирована в самой системе. Стандартный механизм ВызватьИсключение в 1С при работе с Web-сервисами (SOAP) всегда возвращает HTTP-статус 500 (Internal Server Error), что не позволяет внешнему приложению или веб-серверу корректно обработать ситуацию как отказ в доступе (401). Рассмотрим подробнее, почему это происходит и какими способами можно добиться желаемого результата.
Для начала проанализируем архитектуру работы веб-сервисов в 1С. Когда запрос поступает на веб-сервер (IIS или Apache), происходит следующее:
Если мы внутри кода 1С решим, что пользователю "нельзя" входить, и вызовем исключение, сеанс 1С завершится аварийно. Для веб-сервера это выглядит как внутренняя ошибка приложения, поэтому он честно возвращает статус 500. На этом этапе авторизация уже считается успешно завершенной на уровне протокола HTTP, и откатить её назад программно внутри SOAP-метода невозможно. Выясним, какие альтернативные пути существуют для решения этой задачи.
Если ваша архитектура позволяет выбирать тип сервиса, наиболее правильным решением будет использование HTTP-сервисов вместо Web-сервисов (SOAP). В HTTP-сервисах разработчик обладает полным контролем над HTTP-ответом, включая его тело, заголовки и статус-код.
Разберем по шагам, как вернуть ошибку 401 в обработчике HTTP-сервиса:
Функция ИмяМетодаГет(Запрос)
Если Не ПроверитьДоступПользователя() Тогда
// Создаем объект ответа с кодом 401
Ответ = Новый HTTPСервисОтвет(401);
// Обязательно добавляем заголовок для корректной реакции клиента
Ответ.Заголовки.Вставить("WWW-Authenticate", "Basic realm=""1C:Enterprise""");
// Можно добавить пояснение в тело ответа
Ответ.УстановитьТелоИзСтроки("Доступ запрещен: проверка бизнес-логики не пройдена.");
Возврат Ответ;
КонецЕсли;
// Продолжение логики метода...
Ответ = Новый HTTPСервисОтвет(200);
Возврат Ответ;
КонецФункции
Использование объекта HTTPСервисОтвет позволяет веб-серверу зафиксировать именно ошибку 401 в своих логах, а клиентская база сможет корректно обработать ситуацию как отказ в авторизации.
Начиная с версии платформы 8.3.7, 1С поддерживает модули расширения аутентификации. Это мощный инструмент, который позволяет вынести логику проверки прав "за скобки" самого метода веб-сервиса. Посмотрим на этот механизм:
Вы можете создать внешнюю библиотеку или использовать специализированные настройки платформы, которые будут проверять условия доступа до того, как будет поднят полноценный сеанс 1С. Если проверка во внешнем модуле не проходит, платформа сама вернет 401 статус. Этот метод сложен в реализации, так как требует навыков системного программирования, но он наиболее производителен, так как не тратит лицензию и ресурсы на создание сеанса для "запрещенного" пользователя.
Если переход на HTTP-сервисы невозможен и нужно оставить SOAP, проанализируем вариант с использованием промежуточного сервера, например Nginx. Это решение часто называют "базой-прокладкой" или проксированием.
Логика работы будет следующей:
auth_request делает быстрый подзапрос к легковесному HTTP-сервису 1С или скрипту, который проверяет: "Можно ли этому пользователю сегодня заходить?".Этот способ позволяет добиться того, чтобы в логах внешнего веб-сервера (Nginx) фигурировала ошибка 401, при этом основная база 1С даже не будет запускать тяжелый SOAP-процесс для неавторизованного запроса.
Рассмотрим еще один практический совет, который упоминался на форумах. Если доступ ограничивается на длительный период (например, на весь день), можно использовать регламентное задание в Базе-1. Проанализируем ситуацию: мы можем программно менять пароль пользователя или отключать его учетную запись в списке пользователей 1С (через ПользователиИнформационнойБазы).
Пример логики:
Процедура ОграничитьДоступПользователям()
ПользовательОбъект = ПользователиИнформационнойБазы.НайтиПоИмени("WebUser1");
Если НужноЗаблокироватьДоступ() Тогда
// Вариант 1: Меняем пароль на случайный
ПользовательОбъект.Пароль = Строка(Новый УникальныйИдентификатор());
// Вариант 2: В версиях с поддержкой можно отключить аутентификацию 1С
// ПользовательОбъект.Аутентификация1СПредприятия = Ложь;
ПользовательОбъект.Записать();
КонецЕсли;
КонецПроцедуры
В этом случае, когда пользователь попытается подключиться, веб-сервер (IIS/Apache) не сможет сопоставить логин/пароль с данными в 1С и самостоятельно выдаст ошибку 401, так как авторизация не будет пройдена на уровне входа в систему. Это самый простой способ добиться 401 ошибки в логах веб-сервера без изменения программного кода сервиса.
Независимо от выбранного способа, помните, что для корректной работы браузеров и некоторых клиентов 1С при получении 401 ошибки сервер обязан отправить заголовок WWW-Authenticate. В этом заголовке указывается тип аутентификации (обычно Basic) и "realm" (область доступа). Без этого заголовка многие системы воспримут ответ 401 как ошибку конфигурации сервера, а не как сигнал к повторному вводу пароля.
Подведем итог: штатный Web-сервис в 1С не предназначен для программного управления HTTP-статусами. Для гибкого управления ответами используйте HTTP-сервисы или внешние средства фильтрации трафика.