Привилегированный режим. Клиент-сервер #748312

Это из справки конфигуратора по функции Глобальный контекст.ПривилегированныйРежим В режиме "Клиент" показывает, установлен ли привилегированный режим. В клиент-серверном - всегда Ложь. Поясните что это означает и возможно ли в принципе в клиент-серверном варианте узнать с помощью этой функции или какой-либо другой установлен ли привилегированный режим. Попутно вопрос: есть ли возможность выполнять действия программно под другим пользователем (вроди юниксового su)

У общего модуля есть свойство "Привилегированный". Дальше сам.

+ Точнее сама :)

Да есть то оно есть, но вопрос был не об этом. Мне нужно именно <b>узнать</b> установлен ли привилегированный режим или нет. Например из модуля менеджера записи регистра сведений. Еще раз подробнее что мне нужно: 1. Есть регистр сведений. 2. В некоторых случаях при записи в него в общем модуле будет устанавливаться привилегированный режим 3. В модуле записи регистра требуется узнать стоит ли привилегированный режим и если не стоит, то не записывать (устанавливаю отказ). Проблемы бы не было если бы можно было выполнить код под другним пользователем. Можно было бы создать "служебного" пользователя и выполнять из под него

Еще перефразирую. Есть ли гипотетически ситуация, когда функция Глобальный контекст.ПривилегированныйРежим вернет ИСТИНА в клиент-серверном режиме? У меня пока что только ложь.

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

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

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

справка по функции УстановитьПривилегированныйРежим

"цитата из справки" Ага, точно. Я забыл, а ты читать не умеешь, так как в этой цитате ответы на все твой вопросы. "Если не владеете матчастью - не лезьте пожалуйста. Мне надо разобраться." Всё, ухожу. Разбирайся сама...

Топай, топай. Разберемся без сопливых. Повторю вопрос, может кто-нибудь все-таки сталкивался: Есть ли гипотетически ситуация, когда функция Глобальный контекст.ПривилегированныйРежим вернет ИСТИНА в клиент-серверном режиме?

Всем спасибо. Решила свою задачу через параметры сеанса. Но по сабжу ответа так и не нашла. Если кто-то что-то по этому поводу знает - отпишите; мне интересно с этим разобраться - в будущем пригодится.

В клиент-сервере на стороне клиента установить привилегированный режим нельзя. Можно только на стороне сервера, только там его и можно проверить.

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

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

имеется в виду, что в клиент-серверном варианте в режиме "Клиент" всегда ложь.

Ок, тогда что означает вторая строчка? В режиме "Клиент" показывает, установлен ли привилегированный режим

Ну и бабы нынче пошли.. жесть

Катя, не будь таким агрессивным. Тебе же на пальцах объяснили. А ты упираешься.

Для клиент-серверного варианта дело обстоит так. Для управления привилегированным режимом существуют метод УстановитьПривилегированныйРежим(Режим), где Режим - истина или ложь. при этом вызов этого метода что-то меняет только на сервере, а на клиенте он смысла не имеет. То есть на клиенте ни включить, ни выключить его нельзя. Более того, на клиенте и в проверке режима смысла нет, поскольку он на клиенте всегда выключен. То есть в справке тупо опечатка - в клиент-сервером варианте не клиенте ПривилегированныйРежим всегда возвращает ложь. Чего не скажешь про файловый вариант - там привилегированный режим успешно включается на клиенте и эта хреновина таки может вернуть истину. По крайней мере на 8.3.5.1231 это точно так

Да, скорее всего вы правы. Я тоже кроме опечатки других объяснений не нахожу.

забыл сказать - задача "проверить привилегированный режим" смысла не имеет: 1. Установить привилегированный режим может только программист кодом 2. Привилегированный режим самоотключается, как только поток управления выходит из метода, в котором этот режим установлен по этому вот эта проверка даже склеротикам не нужна - забыл, включен ли режим, посмотри строчки выше да и всё. Может, для файловой только, но и то сомнительно.

А вот тут вы не правы. В описанной мной задаче запись "Отказ" устанавливается в зависимости от того, был ли установлен привилегированный режим. При чем "отказ" устанавливается(или не устанавливается) не в том же модуле, в котором устанавливается привилегированный режим. Т.е. проверка привилегированного режима имеет смысл для данной конкретной задачи. Не стану объяснять почему не ипользую тут механизм ролей, будем априори считать что он тут не подходит. Грубо говоря мне ПривелигированныйРежим нужен мне как глобальная переменная доступная для чтения-записи.

Имей ввиду, что это будет серьезная уязвимость. Злоумышленник просто напишет короткий скрипт на VBS, который запустит 1С, установит твою константу установит Visible = true и будет работать в привелигированном режиме

ты справку-то внимательно почитай: есть немного поразмыслить над написанным, то становится очевидно, что, если режим проверяется не в той же процедура, в которой устанавливается, то в момент проверки он будет ===Ложь. За исключением случаев, когда проверка происходит в привилегированном модуле.

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

Злоумышленник ничего не сделает, если у него нет на то установленных прав. Иначе приведите пример скрипта, включающего ПривилегированныйРежим. Учтите, что есть еще понятие БезопасныйРежим, в котором, например, запускаются внешние обработки.

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

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

Про права. Если есть рутовый доступ к системе, то права можно получить к чему угодно, но это уже не в моей 1С-ной зоне ответственности.

что значит "контролировать запись в регистр"? Как это контролировать в реальном мире проявляется?

Через доп. свойства правильнее, ИМХО.

может сначала поймем, чего там хотят?

Это значит устанавливазть "Отказ" в значение Истина или не устанавливать.

какое привилегированный режим имеет отношение к этому "Устанавлвать или нет"?

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

Хотят Отказ = Истина, если при записи набора не установлен привилегированный режим. Я бы это сделал через роли/доп права пользователя, но ТС отчего-то не хочет права настраивать.

в нужном вам модуле делай так: в модуле набора записей перед записью делай так: Можно = Ложь;

Все правильно пишите. Но вот тут уже написала, что права настраивать тут не вариант.

и ни каких привелегированных режимов, ни каких новых метаданных и долбанутых параметров сеансов. Только код

, тебе плюс в карму за телепатические сспособности

+ а, пля, при вызове Свойство надо вторым параметром переменную Можно всунуть. Поторился

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

почитай справку-то внимательно про ДополнительныеСвойства

+ вот эту РегистрСведенийНаборЗаписей.<Имя регистра сведений> (InformationRegisterRecordSet.<Имя регистра сведений>) ДополнительныеСвойства (AdditionalProperties) Использование: Только чтение. Описание: Тип: Структура. Может использоваться в тех случаях, когда необходимо хранить некоторые значения, связанные с объектом, на время выполнения некоторых операций, без изменения объекта. Например, при обработке событий в подписке на события. Доступность: Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер).

О, вот это хороший совет. Я не про тот механизм доп. свойств подумала. Спасибос, а то я еще новичок.

этот совет в был дан. Я только букв добавил

Ну вот видимо этих буков и не хватало. :)