Всем привет. Есть ли возможность ограничить доступ к oData пользователям? И что вообще с безопасностью в этом интерфейсе?

(0) Nginx поставь как реверсивный прокси и что хочешь и как хочешь ограничивай и заодно сможешь и кешировать при необходимости.

Тоесть со стороны 1С никаких огрничений нет? если опубликовал стандартный oData то она становится доступен каждому пользователю базы. Возможно здесь что-то сделать без настроек веб сервера? Если выключать вывод данных пользователю, то он узнав об oData подключится к базе через Excel и скачает.(

"При чтении и записи данных с помощью REST интерфейса платформа выполняет все обычные проверки прав и вызывает обработчики событий, за исключением проверки заполнения."

(3) Замечательно сказано. Но, по факту: публикую типовую БП КОРП, создаю пользователя с правами "Только чтение" захожу в базу, вывод контрагентов в список отключен. прохожу по ссылке под тем же пользователем ../odata/standard.odata/Catalog_Контрагенты?$format=json   и сохраняю список.

если чтение есть, то по одата будет доступен

(5) Да, явно не доработка. В таком случае только ограничивать фаерволом или настройками веб сервера 80 порт и разрешать только определенным ip

При этом oData "Благодаря универсальности и кроссплатформенности мы позиционируем автоматически генерируемый REST интерфейс как основной инструмент для интеграции со сторонними системами."

делай лучше отдельные сервисы и под них юзеров заводи

(0) А не вариант всех пользователей сделать на кириллице, а пользователя для одаты завести на латинице? Одата же не работает с пользователями на кириллице.

(9) все прекрасно работает

(8) да, прийдется писать http сервис с нужными функциями в виде расширения и публиковать его. А хотелось без писанины на автоматическом rest.

(9) работает, хоть и ни хотелось бы

(11) Ты издеваешься?
Отдельного пользователя и разруливаешь правами по доступу, прочим в odata не пускаешь.
Или ставишь Nginx и там рулишь отдельно для путей как надо, можно даже фильтрацию замутить по желанию.
Это когда вместо всех контрагентов выводят только разрешенных или фигу по центру.

А для odata не нужно право на "Внешнее соединение"?

Проще профиль свой создать под пользователя

О, знатоки Одаты собрались! Срошу здесь)
Я правильно понял что в запросной строке нельзя одновременно наложить filter и select?
Допустим я хочу выбрать организацию с ИНН = "11111111111111" и вернуть только ссылку:
http://192.168.1.1/MyBase1c/odata/standard.odata/Catalog_Организации?$filter=ИНН eq '11111111111111'?$select=Ref_Key
В ответ упорно приходят все поля. На ИТС тоже нигде не нашел ни примера, ни упоминания о совместном использовании filter и select.

Так найтись-то может больше одной записи

(13) "Отдельного пользователя и разруливаешь правами по доступу, прочим в odata не пускаешь."  - не работают так права на oData. Да, веб сервером можно рубануть по ip. (14) "Внешнее соединение" - необходимо для обмена БП <-> ЗУП например.

(18) "не работают так права на oData" // Он тебе про то, что опубликовать одату под алиасом, к которому (на веб-сервер) можно обратиться только под одним каким-то пользователем, а не про пользователей ИБ

+(17) Если фильтр по гуиду, то селект работает

(19) ок, понятно, Basic аутентификация на 80 порт, тоже вариант, спасибо

(11) да и на старых упп нет расширений, так что http сервис сработает только для новых кофигураций.

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

(18) для обмена можно создать специального пользователя. Если есть права на внешнее соединение и чтение, то это уже дыра. Независимо от публикации odata

(23) Хочу роль у которой можно указать доступ к odata и дать ее одному пользователю ИБ для обменов. Да, в идельном мире RLS тоже должны работать, вдруг другой пользователь может выводить данные но не все, он подключит Excel, Power BI и тд.

(24) Дыры нет, запуск внешних обработок отключен. Стандартный обмен настроен в папку с доступом только под пользователем сервера 1С. Пользователь только жмет кнопки, к файлам обмена у него доступа нет.

Хочешь защиту делаешь свой http-сервис "обертку" или иначе "прокси", который имеет полный доступ к odata 1С на снаружи пускает только кого надо и к тому чему надо.

(27)+ В смысле на чем угодно вне 1С это делаешь.
Предлагаю делать на Go там это очень просто и компилируется в обычный exe или можно win-службу сделать.

(28)+ Но это можно и средствами apache или nginx попробовать урезать, хотя и гибкости маловато.

(26) При чём здесь стандартный обмен и запуск обработок? Ну подключится он через COM и сольёт всё что может прочитать.

(25) В чём проблема? В новых типовых право на внешнее соединение выделено в отдельную роль.

(30) Верно. Проблема только в том, что нельзя ограничить odata отдельно от остальных интерфейсов.

А разве нельзя опубликовать несколько точек входа oData? Каждой точке входа - свои права (свой юзер в vrd-файле). Конечно, набор таких точек входа будет фиксирован, например, по филиалам.

(31) Так другие внешние интерфейсы ты точно также не можешь ограничить. Поэтому просто не давай права на внешнее соединение пользователем с клиентским доступом. Для внешней интеграции используй специальных служебных пользователей.

(4) Ты точно здоров?
Что такое "Вывод контрагентов в список" и почему невозможность выполнения этой функции должно вдруг помешать браузеру получить через запрос список контрагентов и вывести тебе полученный результат?
Может тебе сначала чуть подразобраться в том, что такое роли 1С и как они работают?

(31) Ты бредишь
Что за чушь ты несешь?

Завтра надо было заводить ветку, поржали бы и с ТС и с собравшихся икспердов :))

(34) проходите мимо

(36) Мы уже с вашей ветки поржали, отойти не можем.

(38) Отойдешь, не переживай. Попозже. Все мы отойдем. Когда-нибудь.

(36) Завтра у тебя похоже похмелье будет. Ты не ту ветку апнул))

(32) в .vrd файле помоему ничего о пользователях не определяется https://its.1c.ru/db/v837doc#bookmark:adm:TI000000379

(41) В атрибуте "ib" можно указать пользователя ИБ, используемого по умолчанию. Тогда этот опубликованный алиас не будет "запрашивать" аутентификацию и все будет работать строго под этим одним указанным пользователем. Я ж в (19) про это писал.

+(42) По факту делаешь так, чтобы в алиас, где одата открыта, можно было авторизоваться только под одним пользователем ИБ, прописанным в этом алиасе (vrd)

А саму базу (для тонкого / веб-клиента) публикуешь под другим алиасом, где одата закрыта и где никакой пользователь ИБ в атрибуте "ib" не прописан.