Добрый день. Написал свою интеграцию с внешней системой через входящие HTTP-сервисы. Отдельная машина с веб-сервером висит в интернете и принимает запросы, там в .vrd прописан логин и пароль... Авдругчтослучится. Встал вопрос ограничения прав для пользователя, под которым интеграция авторизуется в 1С.

Почитав ИТС и СП, погуглив, не нашел описания, какие права требуются сеансу HTTP-сервиса? Что из себя представляет этот сеанс? Это Веб-клиент? Это Automation? Это Внешнее соединение? Это Птица? Это Самолет?

Вдруг, кто уже решал подобную задачу, поделитесь мудростью. Уверен, следующим поколениям это поможет.

для начала попробуй научиться читать

https://v8.1c.ru/platforma/http-servisy/ - тут отсылка к веб-сервисам
https://v8.1c.ru/platforma/web-servisy/ - тут они сами подробно

(0) "там в .vrd прописан логин и пароль" - вот тут ответ на твой вопрос

>Это Веб-клиент? Это Automation? Это Внешнее соединение?

это не то, ни  другое ни третье

(0) Там права на каждый метод http-сервиса можно раздать, но прям запретить пользователю работать с http-сервисом вроде нельзя.

Права на сервис, внутри все через привиленированный режим

(3)+ http://1clenta.ru/pattern/146
#Если НаСервере Тогда
#КонецЕсли

или просто
#Если Сервер Тогда
#КонецЕсли

У меня подобный http-сервис = телеграм-бот.
Для него отдельные логин/пароль прописаны в конфигурационном файле апача.
В 1С для пользака только использование методов данного сервиса (галки стоят у роли).
Внутри привилегированный режим в коде.
Все равно за рамки логики кода методов сервиса уйти невозможно (при грамотном проектировании).

(1) Взаимно. Все эти ссылки, более глубокие ссылки, информацию по модулю расширения веб-сервера я уже читал. Нигде не указывается о том, какой тип соединения создается.
Цитата: "В случае клиент-серверного варианта работы этот модуль будет исполняться в кластере." Это мой вариант, жаль только что "Кластер серверов «1С:Предприятия 8» является логическим понятием и представляет собой совокупность рабочих процессов, обслуживающих один и тот же набор информационных баз.".

То есть конкретный тип процесса опять же не понятен. Какие галки ставить в роли на конфигурацию? Или достаточно дать права на сам сервис?


(2) Настройкой Kerberos мы сейчас занимаемся, но даже если перейдем на аутентификацию средствами ОС, это не решает проблему разделения прав доступа.

(4) Запретить пользователю работать с сервисом задачи не стоит. Задача в обратном - разрешить работать только с сервисом и связанными с ним объектами.

(5) А есть источник откуда информация? Или на опыте?

(7) На конфигурацию галочек вообще не стоит?

(9) здравый смысл

(10) По началу я для справочников начал ставить, но потом перешел на привилегированный режим и забыл про это.
Формально где-то галки стоят на справочники. На права в ветке "конфигурация" не стоят.

(12) Привилегированный режим делаете просто методом в коде? Я вроде настройки сервиса все пролез - никаких галочек типа как у общего модуля не нашел.

Зачем привилегированный режим? Пользователь, допустим, прописан в default.vrd. Добавляем ему новую роль. У этого пользователя должны быть права на доступ к самому http-сервису (у роли - флажок напротив соответствующего http-сервиса). Далее варианты:
1. Этому же пользователю кроме новой роли выдаем другие роли, которые подразумевают доступ к нужным объектам конфигурации. Это самый быстрый вариант.
2. Второй вариант, более правильный, добавление в новую роль прав доступа к нужным объектам. Причем необходимо иметь в виду:
2.1 Если просто берем данные из СУБД запросом или другим способом (не СКД), то достаточно прав только на чтение объектов, просмотр можно убрать. Это повышает уровень безопасности.
2.2 Если выбираем данные с помощью СКД, то у роли должны быть права на чтение и просмотр, иначе СКД вернет пустой результат запроса.
Плюс второго варианта - роли можно не устанавливать права на запуск веб-, тонкого и толстого клиента. Тогда при подключении к опубликованной базе запустить ее не получится, что хорошо с точки зрения безопасности.

(14) Интерфейсной части у http-метода нет. СКД, веб, тонки и толстый клиент не нужны. По моему "здравому смыслу". По нему же я предполагал, что для создания сеанса HTTP-сервиса в кластере нужна одна из галочек в правах на конфигурацию.
Отвечаю на свой же вопрос: "Какие права на конфигурацию нужны пользователю в 1С для работы с HTTP-сервисом?"
Никакие.

Отсюда резонный вопрос:
Какие галочки нужны в правах объектов конфигурации?
В первую очередь галочки на использование методов самого сервиса.
Так же галочки на чтение и изменение нужны только на связанные объекты, которые затрагивает метод.

Мой метод имеет права перезаписывать документы и объекты справочников. Их в свою очередь трекают типовые подписки, которые в том числе контролируют границы запрета изменения данных и.т.п.
Чтобы не перебирать всю конфигурацию, проверяя все сценарии использования сервиса и кто ему отрубит права, я выдал общему модулю сервиса галочку Привилегированный.

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