сама функция

экзепшн выкинет и никаких возврат и отказ не надо

это ж внутренняя штука, она проверяет реквизиты объекта, где установлено "выдавать ошибку", да?

Просто сообщение будет, эксепшена не будет.

С бодрым. Что-то не могу регулярку на имя ветки в gitlab-ci настроить. Из-за русского языка могут быть проблемы?

коллеги, что это может быть за ошибка в ЖР?

Расширение / кэш / файл со скобочными заголовками и т.д.
Может и платформа.

Пожаловался и получилось ;) всем спасибо

Парни у меня вот такой вопрос:
Есть мобильное приложение на 1С. Оно взаимодействует с "большой базой" средставми web-сервисов.
С МП предполагаетя работать из сети Интернет. Требуется создать контур безопастности, из которого исключить сервера 1С:Предприятия.

Просто опубликовать web-сервисы на web-сервере с SSL меня не устраивает:
1. Можно устроить DDoS атаку и пострадает сервер 1С:Предприятие
2. Можно устроить атаку по подбору паролей. А вводить сложные пароли на мобильнике так себе идея.

Я вижу 3 пути решения:
1. Поднять VPN и настроить его на телефоне
2. Поднять центр сертификации, а на web-серверах авторизовать клиента по сертифкату, + ИмяПользователя/пароль уже на 1С:Предприятие
3. Поднять прокси-сервер, который будет проверять от клиента заголовки HTTP-запросов (какие-то ключи/токены там передавать), при успехе транслировать запросы на сервер 1С:Предприятие

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

По поводу п.2
Мне идея нравится, старый добрый, проверенный способ.
Но есть баг в платфрме 1С:Предприятие. который приводит к падению мобильного приложения. На hotline уже написал, но они пока морозятся.
И мне не удалось установить сертификат пользователя на в Андроид, а потом воспользоваться им из Мобильного приложения. Если интерестно, можно обсудить.

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

4. nginx перед веб-сервером 1С

И что? Он как авторизовывать будет?

Он не будет авторизовавыть, он будет ограничивать RPS

также как и без него)

Защита от DDoS. Буду иметь в виду. Но проблема сложных паролей не уходит.

А зачем какие-то пароли? 2фа сделай.

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

А есть что-то что можно использовать в качестве этой прослойки? Может быть есть какие-то
У меня пока идеи только на php сколхозить прокси, который будет из заголовков запроса читать секретный ключ и сверяться не отозван ли он.

прикинуть реальную необходимость и бюджет)
если из возможностей только "колхозить на php", то ничего дельного предложить не могу.

Но вот то что Вы сказали это из моего п.3

Ага, примерно так. Зависит от исполнения.
Общий посыл в том, что если делаете публичное апи для  какого-то приложения, то 1С в чистом виде не должно выступать в роли бэкэнда.
Но везде есть свои исключения. Может у вас там пользователей человек 10 максимум и RPS около ноля.