В процессе разработки и сопровождения конфигураций на платформе «1С:Предприятие 8.3» программисты часто сталкиваются с неочевидным поведением системы при совместном использовании расширений и привилегированных модулей. Особую загадочность приобретают ошибки, которые воспроизводятся не сразу, а только при определенных условиях — например, после того, как сеанс пользователя некоторое время находился в состоянии покоя.
В данной статье мы подробно разберем крайне интересную и распространенную проблему: почему при вызове процедур записи или распроведения документов из расширения через привилегированный общий модуль возникает ошибка «Нарушение прав доступа», причем происходит это строго после того, как база постоит без дела около 20 минут. Мы проанализируем внутренние механизмы платформы, выясним причины такого поведения и рассмотрим несколько эффективных способов решения этой проблемы.
Представим стандартную рабочую ситуацию. В информационной базе (например, «1С:Управление торговлей 11») развернуто расширение конфигурации, которое модифицирует рабочее место кассира (РМК). Задача расширения — автоматически выполнять перемещение товаров с оптового склада на розничный непосредственно перед продажей, а в случае отмены операции — программно распроводить созданный документ перемещения.
Для выполнения этой операции под учетной записью кассира (у которого нет полных прав на распроведение документов перемещения) разработчик логично переносит код отмены проведения в привилегированный общий модуль основной конфигурации. Код вызывается из модуля расширения. На первый взгляд, схема должна работать идеально:
Записать(РежимЗаписиДокумента.ОтменаПроведения).И действительно: в течение дня кассир активно бьет чеки, и никаких ошибок не возникает. Однако стоит кассиру отойти на обед или оставить программу бездействующей примерно на 20 минут, как при первой же попытке совершить аналогичную операцию система выдает критическую ошибку:
Ошибка при вызове метода контекста (Записать): Нарушение прав доступа!
Давайте разберем по шагам, почему привилегированный режим внезапно «отключается» именно через 20 минут бездействия.
Первый ключ к разгадке кроется в самом временном интервале. Цифра в 20 минут (или 1200 секунд) является дефолтным системным параметром для механизма спящих (пассивных) сеансов в платформе «1С:Предприятие».
Рассмотрим, как это функционирует на уровне сервера приложений:
В нормальных условиях этот процесс происходит незаметно для пользователя. Однако при использовании расширений в старых версиях платформы (включая ветку 8.3.8 и ранние релизы 8.3.9) в этот момент срабатывает критический баг платформы.
Выясним, что происходит с правами и контекстом безопасности расширения при выводе сеанса из спящего режима.
Для любого расширения в базе данных существуют критически важные свойства: «Безопасный режим» и «Защита от опасных действий». По умолчанию, если у расширения включен безопасный режим, платформа жестко ограничивает его возможности. В частности, в безопасном режиме полностью блокируется переход в привилегированный режим. Даже если код обращается к привилегированному модулю, директива привилегированности игнорируется, и код выполняется с правами текущего пользователя (кассира).
Разработчики обычно снимают флаг «Безопасный режим» в свойствах расширения, чтобы разрешить выполнение привилегированных операций. Но в платформенных механизмах восстановления спящего сеанса кроется ошибка:
Когда спящий сеанс кассира аварийно пробуждается после 20 минут бездействия, платформа восстанавливает его рабочее окружение. В момент самого первого серверного вызова настройки безопасности примененных расширений считываются некорректно или восстанавливаются с задержкой. В результате система на долю секунды считает, что расширение запущено в безопасном режиме по умолчанию.
В этот короткий промежуток времени кассир пытается отменить проведение документа. Платформа видит вызов привилегированного модуля из расширения, которое она ошибочно считает «безопасным», блокирует переход в привилегированный режим, выполняет код с правами кассира и закономерно возвращает ошибку Нарушение прав доступа при попытке записи документа.
Дополнительным фактором выступает время жизни серверного кэша модулей с повторным использованием возвращаемых значений (функции с директивой ПовторноеИспользование).
Время жизни такого кэша в рамках сеанса также составляет ровно 20 минут после вычисления или 6 минут после последнего обращения. Если логика проверки прав доступа или проведение документа опирается на такие кэшируемые функции, то через 20 минут бездействия кэш гарантированно очищается.
При первом действии после паузы платформа инициирует полный пересчет этих функций. Если в этот момент сеанс только «просыпается» и права расширения из-за бага инициализации зажаты в безопасном режиме, инициализация параметров прав падает с ошибкой доступа, которая затем кэшируется или приводит к аварийному завершению транзакции.
---
Рассмотрим несколько практических способов устранения данной ошибки, начиная от самых правильных и заканчивая обходными путями (workarounds), если оперативное вмешательство в систему ограничено административными регламентами.
Поскольку данное поведение является задокументированной ошибкой самой платформы 1С, наиболее надежным и правильным решением будет обновление платформы до стабильного релиза, в котором этот баг был исправлен.
Проблема некорректного восстановления контекста безопасности расширений при выводе сеанса из спящего режима была устранена разработчиками 1С в последующих релизах. Рекомендуется обновиться на версию платформы не ниже 8.3.9.2033, а лучше — на актуальные релизы веток 8.3.12, 8.3.16 или выше (в зависимости от требований вашей конфигурации).
Если быстро обновить платформу на сервере не представляется возможным (например, из-за несовместимости другого оборудования или длительного процесса согласования обновлений), вы можете временно отключить или значительно увеличить время засыпания сеансов.
Для этого выполним следующие шаги в Конфигураторе:
1200 секунд (20 минут).28800 секунд (что эквивалентно 8 часам — стандартной рабочей смене кассира), либо установите значение 0, чтобы полностью отключить засыпание сеансов (обратите внимание, что отключение засыпания может увеличить расход серверных лицензий).После этого сеансы кассиров не будут переходить в спящий режим в течение рабочего дня, и контекст безопасности расширений не будет сбрасываться.
Проанализируем, как можно обойти эту ошибку непосредственно в коде конфигурации или расширения. Для начала выполним диагностику в коде перед вызовом транзакции записи. Рассмотрим пример функции, которая проверяет реальное состояние режимов системы:
Процедура ВыполнитьОтменуПроведенияНаСервере(ДокументСсылка) Экспорт
// Проверим реальное состояние безопасного режима
Если БезопасныйРежим() Тогда
ЗаписатьЛогСобытий("Внимание! Расширение запущено в безопасном режиме, привилегированный режим недоступен.");
КонецЕсли;
// Попытка установить привилегированный режим
УстановитьПривилегированныйРежим(Истина);
Если Не ПривилегированныйРежим() Тогда
// Если режим не установился, значит мы зажаты в контексте безопасного режима
ВызватьИсключение "Не удалось установить привилегированный режим из-за ограничений безопасности платформы!";
КонецЕсли;
// Выполнение целевого действия
ОбъектДокумента = ДокументСсылка.ПолучитьОбъект();
ОбъектДокумента.Записать(РежимЗаписиДокумента.ОтменаПроведения);
УстановитьПривилегированныйРежим(Ложь);
КонецПроцедуры
Если диагностика показывает, что БезопасныйРежим() возвращает значение Истина, а привилегированный режим не устанавливается из-за зависания платформенного контекста, можно применить архитектурный обход: выполнение операции в фоновом задании.
Фоновые задания в 1С всегда запускаются в чистом серверном контексте, на который не влияют настройки «заснувшего» сеанса пользователя. Мы можем передать задачу по отмене проведения документа фоновому заданию, которое выполнит ее со стопроцентной гарантией соблюдения привилегированных прав:
Процедура ОтменитьПроведениеДокументаЧерезФоновоеЗадание(ДокументСсылка) Экспорт
ПараметрыЗапуска = Новый Массив;
ПараметрыЗапуска.Добавить(ДокументСсылка);
// Запускаем фоновое задание, которое выполнится в привилегированном контексте
ФоновыеЗадания.Выполнить("МойОбщийМодульСервер.ВыполнитьОтменуПроведенияВФоне", ПараметрыЗапуска);
КонецПроцедуры
// Метод в привилегированном модуле основной конфигурации
Процедура ВыполнитьОтменуПроведенияВФоне(ДокументСсылка) Экспорт
ОбъектДокумента = ДокументСсылка.ПолучитьОбъект();
ОбъектДокумента.Записать(РежимЗаписиДокумента.ОтменаПроведения);
КонецПроцедуры
Самый простой и быстрый способ, к которому прибегнул автор темы на форуме, — это предоставление пользователю (кассиру) явного права на выполнение данной операции в его профиле групп доступа.
Если предоставить роли кассира право «Отмена проведения» для конкретного документа («Перемещение товаров»), то даже при возникновении платформенного бага со сбросом привилегированного режима, выполнение метода Записать() пройдет успешно, так как у текущего пользователя теперь будет достаточно собственных прав для выполнения этого действия.
Однако помните, что этот способ снижает безопасность системы, так как кассир получит возможность распроводить документы перемещения вручную через стандартный интерфейс (если он доступен), что не всегда допустимо с точки зрения бизнес-логики предприятия.
Используйте предложенные рекомендации, своевременно обновляйте платформу и корректно настраивайте параметры спящих сеансов на сервере «1С:Предприятие 8.3» для стабильной работы ваших прикладных решений!