1с ошибка доступа к сокету методом запрещенным правами доступа

Обновлено: 07.01.2025

Ошибка в 1С 8.3 Нарушение прав доступа появляется при попытках обращения пользователя к объекту, прав на который у него нет. Очень часто это происходит при вводе нового пользователя в 1С, доработке программного кода и обновлении программы.

Прочитав эту статью, вы:

узнаете, на что обращать внимание при возникновении ошибки;
получите рекомендации по ее устранению;
ознакомитесь с ответами экспертов БухЭксперт8 на вопросы, связанные с возникновением ошибки.

Причины ошибки

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

обновление программы на новый релиз;
попытка чтения или записи данных справочника, документа или регистра пользователем, не имеющим прав на объект;
использование внешних обработок и отчетов без установки пользователю специальной роли;
ошибка задания прав новому пользователю 1C.

Ошибка обновления

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

При появлении ошибки Нарушение прав доступа после обновления программы нужно выполнить следующие действия:

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

БухЭксперт8 советует всегда делать перед обновлением архивные копии базы данных. Это поможет восстановить базу при неудачном обновлении.

Нарушение прав доступа при чтении данных

В 1С существует набор специальных объектов Роль , которые описывают разрешенные действия пользователей. Роли задаются разработчиками в Конфигураторе 1С. При работе в 1С можно пользоваться только этим предопределенным набором. Самостоятельно ввести новую Роль без доработки Конфигурации невозможно.

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

Пользователь, которому назначили роль Чтение контрагентов , может считывать данные справочника Контрагенты , но при обращении к справочнику Банки получит ошибку Нарушение прав доступа .

Нарушение прав доступа при записи данных

При записи изменений данных в справочниках, документах и регистрах программа проверяет наличие соответствующих прав у пользователя также, как и при чтении данных,

Пользователь, которому назначена роль Добавление и изменение сотрудников , может редактировать данные справочника Сотрудники , но при попытке изменения данных банка получит ошибку Нарушение прав доступа .

Работа с внешними отчетами и обработками

Для работы с внешними отчетами и обработками пользователю нужно назначить одну из ролей:

Полные права ;
Интерактивное открытие внешних отчетов и обработок .

Как добавить роль Интерактивное открытие внешних отчетов и обработок , описано в статье Как добавить пользователю с правами Бухгалтер права запускать внешние отчеты и обработки?

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

Добавление нового пользователя

При добавлении новых пользователей БухЭксперт8 рекомендует использовать типовые Профили группы доступа в 1С: раздел Администрирование — Настройки программы — Настройки пользователей и прав .

В 1С заложена автоматическая проверка прав того набора объектов 1С, который определяется профилем групп доступа:

Программа скроет все объекты, на которые у пользователя нет прав:

Чтобы ограничить возможность изменения документов определенным пользователям, можно даже не устанавливать специально Дату запрета изменения . Программа сама не даст сохранить изменения пользователям с ограниченными правами:

Использование типовых Профилей групп доступа сводит к минимуму риск возникновения ошибки.

Ответы на вопросы

Ошибка при проведении документа Реализация (акт, накладная)

Создали новую роль в Конфигураторе — только для документа Реализация (акт, накладная) . При записи документа программа отрабатывает правильно, а при проведении — выдает ошибку Нарушение прав доступа .

В чем может быть причина?

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

Если вы указали в новой роли право только на документ Реализация (акт, накладная) , этого недостаточно. По кнопке Дт/Кт уточните, какие регистры используются при проведении документа и добавьте их в новую роль с активными свойствами:

Ошибка при попытке открыть карточку контрагента под определенным пользователем

«Справочник.Контрагенты.Форма.БП_ФормаЭлемента.Форма: Ошибка при вызове метода контекста НаборЗаписей.Прочитать() по причине: Нарушение прав доступа».

Ошибка связана с тем, что у пользователя, который отрывает карточку Контрагенты , нет прав на чтение данных из определенного регистра 1С.

Если в подробном описании ошибки программа не указывает регистр, при записи данных в который происходит ошибка, вам придется выяснить это самостоятельно. Для недоработанной типовой конфигурации Бухгалтерия 3.0 при открытии справочника Контрагенты могут использоваться:

регистр бухгалтерии Хозрасчетный ;
регистр бухгалтерии Курсы валют ;
регистр бухгалтерии Наличие дублей у контрагентов ;
и т. д.

Эти регистры включены в программный модуль справочника Контрагенты .

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

Эта работа требует особой подготовки и квалификации.

Ошибка при открытии внешнего отчета

При попытке открыть внешний отчет 1С появляется ошибка Нарушение прав доступа . Все остальные отчеты внутри программы открываются нормально. В чем может быть причина?

Для открытия внешних отчетов и обработок 1С необходимо добавить пользователю роль Интерактивное открытие внешних отчетов и обработок . После этого он сможет работать с внешним отчетом без ошибок.

См. также:

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Карточка публикации

(1 оценок, среднее: 5,00 из 5)

Данную публикацию можно обсудить в комментариях ниже.
Обратите внимание! В комментариях наши кураторы не отвечают на вопросы по программам 1С и законодательству.
Задать вопрос нашим специалистам можно по ссылке >>

Вы можете задать еще вопросов

Доступ к форме "Задать вопрос" возможен только при оформлении полной подписки на БухЭксперт8

Вы можете оформить заявку от имени Юр. или Физ. лица Оформить заявку

Нажимая кнопку "Задать вопрос", я соглашаюсь с
регламентом БухЭксперт8.ру >>

Как не попасть в ловушку, работая с контрагентами из ЕАЭС

[17.11.2021 запись] Практический переход на ФСБУ 6 и ФСБУ 26 в 1С

Переход на ФСБУ 6/2020 «Основные средства» в 1С по альтернативному алгоритму

Изменения в 2021 году, о которых нужно знать бухгалтеру

[11.10.2021 запись] Учет ОС по-новому: ФСБУ 6/2020, ФСБУ 26/2020, ФСБУ 25/2018

[29.10.2021 запись] Пообъектный учет ОС и подходы к определению и пересмотру СПИ

Настройка прав доступа - одна из самых распространенных задач для разработчиков 1С. Это не значит, что подобные задачи всегда ставятся явно. Большая часть из них связаны с текущей разработкой, ведь новый функционал требует ограничений на использование среди пользователей. Но есть и исключения, когда поступает заказ / задача по ограничению доступа к некоторым данным или функциям в информационной базе.

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

Есть и другие истории, когда с правами все в порядке. Есть толковый администратор, который следит за корректностью их настройки. И все работает какое-то время, пока в дело не вступают разработчики (штатные или с аутсорсинга, не важно!). Множество задач, множество требований, множество ошибок с правами. Такова печальная картина.

Конечно, я дал немного пессимистичную оценку, чтобы подготовить Вас к незабываемому путешествию по типичным ошибкам разработки прав доступа. Мы пройдемся по самым частым проблемам, с которыми приходилось сталкиваться. Это не полный список, поэтому Ваши истории также приветствуются в комментариях.

Обычный процесс разработки

Прежде чем перейти непосредственно к ошибкам, давайте вспомним обычный процесс разработки прав доступа. Все основные настройки доступа выполняются с помощью ролей. Роли - объекты конфигурации, занимающие центральное место в построении модели этих самых прав. Именно с их помощью разработчик может настроить доступ к объектам конфигурации. Они же применяются для более гибкой настройки с помощью разграничений на уровне записей (RLS).

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

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

Внезапные проблемы

Итак, поехали! Какие же ошибки могут быть с правами доступа при разработке?

Просто новый объект

Представьте, что к Вам поступил заказ от клиента: создать новый документ в системе для внесения некоторого пакета документов. Другими словами, нужно добавить документ, который хранит ссылки на другие документы и т.д. Задача ясна. День разработки, после демонстрация клиенту (проверял сам директор!) и можно выкладывать в рабочую систему. Перед обновлением сделаны рассылки, что новый функционал заработает с такого-то числа. Наступает день "икс", Вы вечером обновляете базу и с чувством выполненного долга уходите на сон.

Но утром Вас ждет сюрприз! Никто, кроме директора и системного администратора (да, да! он там главный по 1С) не могут получить доступ к новому документу. В интерфейсе его просто нет!

Догадались в чем дело? Ну, конечно! Новый документ добавлен, функционал отлично разработан, но права на него никто не предоставил.

Следовать лозунгу: "Добавил объект - проверь права!".

А еще лучше - написать Unit-тест, который будет проверять объекты без прав доступа. Посмотрите в сторону

Давать права с разумным подходом.

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

При добавлении новых объектов не стоит делать ставку на роль "Полные права". Нужно либо добавлять новый объект в существующие роли, либо добавлять новые роли. Все же очевидно.

Скроем подсистему

Пришла срочная задача - нужно части пользователей скрыть подсистему "Супер подсистема увеличения продаж".

Проблема в том, что конфигурация наполнена legacy-кодом, а роли конфигурации не имеют четких ограничений между подсистемами. Все связано как какое-то спагетти. А сделать надо еще вчера (ну, Вы понимаете)!

Выпив 3 кружки кофе, решение приходит само. Нужно лишь скрыть всем ролям доступ к этой подсистеме. Именно подсистеме как объекту конфигурации, а все входящие в ее состав объекты вообще не трогать. Только не забыть дать доступ к этой подсистеме для нужной роли (ее даже можно создать отдельно ради такого случая). Гениально!

Есть еще другой путь - доступ на подсистему не менять, а изменить видимость по умолчанию в настройках.

Это будет работать. У вас даже могут принять работу, и Вы разойдетесь с заказчиком рукопожатием. НО! Вы сделаете не разграничение прав доступа, а лишь измените видимость элементов интерфейса. Да, в первом случае доступа к объекту подсистемы не будет, но к объектам из его состава - пожалуйста! Например, в подсистеме был документ "СекрентныйДокумент". Вы идете вот сюда, нажимаете "Перейти по навигационной ссылке" и вводите примерно такую строку.

Имя документа должно быть таким же как в конфигураторе, тогда все сработает. Все! Список документов, доступ к которым нам ограничили, мы открыли. А дальше работаем как нам нужно.

Вариант с настройкой видимости подсистемы еще проще: заходим в настройки интерфейса и включаем видимость для нужной подсистемы.

Как оказалось, права доступа мы и не настроили.

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

Реквизит больше недоступен

Иногда можно столкнуться с задачей - запретить некоторым пользователям просматривать / изменять определенный реквизит у объекта. В ролях можно настраивать "доступ" к отдельным реквизитам.

"Это так круто!", можно услышать от некоторых разработчиков. Действительно, поставил нужные чек боксы и вперед - задача решена!

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

А если данные таким способом можно прочитать, то о каком разграничении доступа может идти речь.

Не используйте эти настройки для решения задач с правами доступа. Это интерфейсные функции.

Для разграничения доступа на изменение реквизитов Вы можете использовать проверки заполнения, события объектов (перед записью, при записи, обработка проведения и др.), в которых реализуете проверки программно. Запретить же просмотр отдельных реквизитов объекта эффективно практически невозможно. Только если дорабатывать все возможные формы, отчеты и другие места конфигурации, добавляя проверки на доступ к нему. Но вот сопровождать такое я бы не взялся.

Есть другой эффективный способ - вынести реквизит в отдельную таблицу и настраивать доступ на нее. Но это уже совсем другая история.

Видимость команд

Выше мы настраивали видимость подсистем. Как уже было сказано, решать так задачи с правами смысла нет, т.к. права на самом деле и не изменяются. По такому же принципу часто поступают не с подсистемами целиком, а с отдельными командами или объектами.

Как и в прошлый раз, по умолчанию пользователь не будет видеть команды в интерфейсе. Но что ему мешает сделать так.

Фиаско? Еще какое!

Повторюсь: настройка видимости и настройка прав доступа - совершенно разные вещи. Никогда не пытайтесь решить вопросы прав доступа с помощью настроек интерфейса.

Новая роль

Выстроенная ролевая модель, четкое разграничение прав доступа. грамотно настроенный RLS! Ваша система эталон работы с правами. И оно понятно, ведь информация в ней чувствительная, ведь это отдел казначейских операций. Сотрудники одного отдела не должны видеть операции соседних подразделений и наоборот. В общем, безопасность на высшем уровне!

Но вот однажды, выпуская новую задачу в рабочую базу, что-то пошло не так! После обновления ВСЕ пользователи стали видеть все заявки, хотя изменения в существующие правила RLS никто не вносил. Что же произошло?

Как Вы догадались - была добавлена новая роль. Нет нет, роль имеет настройки доступа только для тех объектов, для которых действительно нужно. В том числе и для объектов с той самой чувствительной информацией. Вот только есть одна проблема: при добавлении новой роли никто в ней не описал правила RLS, в итоге он перестал работать для всех кому эту роль добавили (в нашем примере ее, допустим, добавили большинству сотрудников).

Как известно, пользователь получает максимальный доступ, который ему предоставляют роли. В нашем случае роль без RLS дает больше прав, чем остальные. Вот платформа их и применяет.

Как же такое вообще можно предотвратить?

Вообще, если в системе есть RLS, то это дополнительная ответственность для разработчиков:

Нужно корректно писать запросы
Необходимо учитывать это в отчетах
При добавлении ролей нужно добавлять правила RLS (это как раз наш случай)
Некоторый код не будет работать с RLS совсем (например, некоторые приемы с объектной техникой работы с данными, или вложенные подзапросы большой глубины и т.д.).
И др.

Так что тут можно посоветовать быть более внимательным и писать Unit-тесты для проверки прав доступа.

RLS не наша тема

Информация выше Вас напугала и теперь использовать RLS никогда не будете? Есть способ проще! Можно в динамических списках, отчетах и других местах подбора данных программно устанавливать отборы на получаемую информацию. Например, добавить ограничения по организации. Вот такой код в событии "При создании на сервере" решает эту задачу.

И ведь все работает! Но раз уж этот подход попал в статью, значит не все так гладко. Проблема в том, что ограничения доступа к данным здесь нет, есть только интерфейсные ограничения. Этот подход еще можно назвать как "костыльный RLS". Его обычно применяют, когда задачу надо сделать еще месяц назад, а в ИТ-отдел уже ломятся сотрудники с требованием ограничить доступ.

Проблема в том, что есть множество других путей получить доступ к этим данным. Предусмотреть все возможные ограничения с помощью программных "костылей" невозможно. Например, пользователь вывел отчет, а в него попал "запретный" документ. Ничто не мешает нам его открыть. Слышу вопрос: "Так в форме документа тоже можно сделать программную проверку при открытии!?". Конечно можно! Но что мне мешает в отчете вывести интересующие меня данные из документа с помощью СКД.

Все защиты пали! А как жаль, ведь потрачены десятки часов работы.

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

Сроки горят? Отлично, "костыль" оправдан! Только не забудьте вернуться к этому вопросу в будущем.

Я сам настрою

И на последок еще один небольшой "фейл". Иногда в системе имеется дополнительный функционал настройки доступа. Например, регистр сведений "Дополнительные права", в котором каждому пользователю добавляются отдельные функции.

Не раз приходилось сталкиваться с такой ситуацией, что права все настраиваются и все работает. Гибкие настройки - мечта администратора и все такое. Но.

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

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

На самом деле

Это далеко не полный список потенциальных ошибок. Скорее это самые простые, распространенные и банальные ситуации. Возможно, Вы уже знакомы с некоторыми из них. Какие-то допускали Ваши коллеги, какие-то коллеги коллег, но точно не Вы!

Скажу Вам по секрету, только никому не рассказывайте: за все время работы с платформой 1С и решениями на ее основе автором были сделаны все перечисленные ошибки. И даже больше!

Но если бы не было ошибок, то и опыта бы не было. А также этой публикации :)

Я думаю, что объект app в порядке (содержащий параметры настроек, объект сеанса с токеном доступа и мой идентификатор пользователя facebook и т. Д.)

Решено . моя проблема - мой брандмауэр "молча" блокировал подключение рабочего процесса ISS к порту 443 . Надеюсь, что хоть кого-нибудь спасу от той же ошибки :)

Если вы получаете ту же ошибку при разработке Windows 8, возможно, вы не включили доступ через частные сети в своем файле Package.appxmanifest :

Проблема была и на моей стороне. Однако я использовал SMTP-клиент для отправки почты. Я запускаю PeerBlock, и он блокирует подозрительные IP-адреса. Я видел, что он блокирует один из IP-адресов, на которые я отправлял, прежде чем он покинул мою сеть. Простое исключение из правила и проблема была решена.

TL; DR брандмауэры и другие инструменты фильтрации интернет-безопасности должны быть проверены, чтобы убедиться, что эта проблема не вызвана вашей стороной.

Проведя небольшое исследование, я обнаружил, что по некоторым причинам «Служба публикации в Интернете» (W3SVC) работает. Остановка и отключение службы решили мою проблему.

Никогда не пользовался этой услугой. Я предполагаю, что установка Visual Studio Community 2013 в прошлом устанавливала и включала эту службу. Когда я впервые столкнулся с проблемой, я подумал, что это проблема с привилегиями, как это имеет место в системах Linux, где приложения, прослушивающие порты 4

Не уверен, что все это было, но ipconfig /release && ipconfig /renew , похоже, у меня сработало.

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

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

Мой использует McCafee, и я снимаю в нем функцию, которая блокирует соединение через сокет для отправки почты, и это сработало.

Отключенный брандмауэр
Отключенный антивирус
Сбросить стек TCP / IP
Перезагруженный компьютер
Подтвержденная строка подключения

Ничего из этого не сработало. Я обнаружил, что проблемой для меня был мой VPN (Astrill). По какой-то причине это приводило к сбою этих соединений localhost. Отключение от VPN устранило мою проблему.

Ошибка Недостаточно прав на исполнение операции возникает после включения в 1С специального механизма Разграничение прав доступа на уровне записей .

Использование этого механизма дает возможность пользователям работать только с определенными объектами.

В 1С Бухгалтерия 3.0 включение Разграничения прав доступа на уровне записей устанавливается: раздел Администрирование — Настройки пользователей и прав — флажок Ограничивать доступ на уровне записей .

Настройка доступа по Организациям выполняется по ссылке Пользователи в разделе Администрирование — Настройки пользователей и прав .

По кнопке Права доступа настраивается доступ пользователям по Организациям .

Из настройки видно, что у пользователя Менеджер нет доступа к записям организации Техномир ООО.

Недостаточно прав на исполнение операции

Разработчики строго следят за тем, чтобы выставленные в настройках права пользователей четко выполнялись. При работе с документами пользователь Менеджер не может видеть документы организации Техномир ООО, к которой у него нет доступа, и менять данные по хозяйственным операциям этой организации.

При обращении к «закрытым» сведениям пользователь Менеджер обязательно получит ошибку.

Менеджер отдела продаж при работе с внешней обработкой Изменение организации в документе Поступление (акт, накладная) при попытке изменить в документе организацию на ООО Техномир получает ошибку Недостаточно прав на исполнение операции .

Ошибка возникает из-за того, что у пользователя Менеджер нет прав изменять документы организации ООО Техномир. Для исправления ситуации ему необходимо добавить права на работу с этой организацией.