Как назначить пользователю право админа из под у.з. самого пользователя
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6) если нет прав администрирования, то не выйдет изменить.
Тогда, как вариант:
Создать роль Администрирование с правами:
"Администрирование"
"Тонкий клиент"
возможно еще несколько прав добавить.
Добавить служебного пользователя, у которого отключить свойство "Показывать в списке выбора"
Этого пользователя можно указать в параметрах командной строки запуска. Так же передавать ПараметрЗапуска, к примеру: /C"Администрирование"
В обработчике модуля приложения ПередНачаломРаботыСистемы проверять ПараметрЗапуска и если есть нужный, тогда уже запускать поиск пользователя и добавление ролей. И завершать работу системы.
Тогда, как вариант:
Создать роль Администрирование с правами:
"Администрирование"
"Тонкий клиент"
возможно еще несколько прав добавить.
Добавить служебного пользователя, у которого отключить свойство "Показывать в списке выбора"
Этого пользователя можно указать в параметрах командной строки запуска. Так же передавать ПараметрЗапуска, к примеру: /C"Администрирование"
В обработчике модуля приложения ПередНачаломРаботыСистемы проверять ПараметрЗапуска и если есть нужный, тогда уже запускать поиск пользователя и добавление ролей. И завершать работу системы.
(16) "служебный" в данном случае не означает замену пользователя по умолчанию. Это обычный пользователь, но без отображения в списке пользователей для выбора при запуске. Просто можно указать как пользователя для запуска из командной строки. Соответственно выполнит(или нет) необходимые действия и завершит работу.
(17) Это прекрасно. Размышляем дальше:
1. У нас несколько пользователей.
2. Кому-то или нескольким или всем - надо дать права админа.
3. Предлагаемое вами решение - запускать некий батник от имени служебного пользователя, который раздаст права админа тому, кто запустил этот батник. После чего пользюк сможет работать под своей учеткой и с правами админа.
Я правильно уловил мысль?
Теперь вопрос - КОМУ эта обработка должна раздать права админа? Как это определить на стадии запуска батника? Для каждого пользюка прописывать в ПриНачалеРаботыСистемы() свой персональный ключ запуска и каждому выдавать ярлык для запуска???
1. У нас несколько пользователей.
2. Кому-то или нескольким или всем - надо дать права админа.
3. Предлагаемое вами решение - запускать некий батник от имени служебного пользователя, который раздаст права админа тому, кто запустил этот батник. После чего пользюк сможет работать под своей учеткой и с правами админа.
Я правильно уловил мысль?
Теперь вопрос - КОМУ эта обработка должна раздать права админа? Как это определить на стадии запуска батника? Для каждого пользюка прописывать в ПриНачалеРаботыСистемы() свой персональный ключ запуска и каждому выдавать ярлык для запуска???
(21) "Хочу сделать обработку, где бы в тестовых они бы сами себе назначали бы админа и могли бы работать." именно это и подразумевает. Единоразовый запуск для добавления роли админа конкретным пользователям. Тем более заранее известно каким пользователям добавить эту роль.
(22) Стоп. Пользюк заходит под своим логином или под служебным??? У автора требование - чтобы из под своего имени. а вы предлагаете некий универсал, под которым все 100500 пользюков всех филиалов назначат себе права админа из под служебной учетки с открытым паролем в строке запуска.
И они запустят.
И не факт, что именно в тестовой базе.
И они запустят.
И не факт, что именно в тестовой базе.
(23) суть требований, дать пользователю в тестовой базе права админа. Чтобы они могли курочить тестовую базу. Достаточно дать права одному текущему пользователю. Он потом может при необходимости и другим роли понаставить.
Зайти под служебным пользователем будет нельзя. Он не отображается в списке выбора пользователей. Да и пароль не известен.
Пользователь заходит под своей учеткой. Запускает обработку.
Эта обработка находит гуид этого пользователя и запускает через КомандаСистемы скрипт запуска базы через командную строку, с передачей имени служебного пользователя, его пароля и параметра системы, в который можно предать полученный ранее гуид.
Чтобы не запускалось это не в тестовой базе, то можно использовать тот же механизм, как типовые определяют, что это КОПИЯ.
Чтобы не светить пароль служебного пользователя, можно из поставки исключить текст общего модуля.
Зайти под служебным пользователем будет нельзя. Он не отображается в списке выбора пользователей. Да и пароль не известен.
Пользователь заходит под своей учеткой. Запускает обработку.
Эта обработка находит гуид этого пользователя и запускает через КомандаСистемы скрипт запуска базы через командную строку, с передачей имени служебного пользователя, его пароля и параметра системы, в который можно предать полученный ранее гуид.
Чтобы не запускалось это не в тестовой базе, то можно использовать тот же механизм, как типовые определяют, что это КОПИЯ.
Чтобы не светить пароль служебного пользователя, можно из поставки исключить текст общего модуля.
(24)
Обычная допобработка с ежесуточным расписанием. С формой настройки (настройка имен тестовых баз и ограничения по пользюкам).
Форма настройки доступна только РЕАЛЬНОМУ админу.
И не надо лохматить бабушку!!!
суть требований, дать пользователю в тестовой базе права админа.
Для этого вполне достаточно регламентного задания, которой раз в сутки по имени базы будет предоставлять всем права админа. Или не всем.
Обычная допобработка с ежесуточным расписанием. С формой настройки (настройка имен тестовых баз и ограничения по пользюкам).
Форма настройки доступна только РЕАЛЬНОМУ админу.
И не надо лохматить бабушку!!!
(26) Админ. РЕАЛЬНЫЙ. Он же есть. Один раз настроить имена баз (копий) в боевой базе - и все, срать на остальные тестовые.
Естественно, в тестовых копиях должны быть разрешены регламентные задания. Ну или как-то по другому этот вопрос урегулировать...
Но вся эта фигня со специальными строками запуска - она и есть фигня.
В крайнем случае - этот регламент может запускаться из боевой базы для настроенного списка тестовых баз.
Да даже и без регламентного задания - зафигачьте в расширение ПриНачалеРаботыСистемы() эту проверку - да и все.
Естественно, в тестовых копиях должны быть разрешены регламентные задания. Ну или как-то по другому этот вопрос урегулировать...
Но вся эта фигня со специальными строками запуска - она и есть фигня.
В крайнем случае - этот регламент может запускаться из боевой базы для настроенного списка тестовых баз.
Да даже и без регламентного задания - зафигачьте в расширение ПриНачалеРаботыСистемы() эту проверку - да и все.
(27) это ответ совсем на другие требования.
Как я понимаю, эти тестовые копии нужны для отладки актуальных данных. Прописанные первоначально тестовые базы не нужны будут со временем.
И не нужно так нервничать. Решать все равно не нам.
Да да. так и заявите фирме 1С, а то повадились бэкапы скриптами делать :)
Как я понимаю, эти тестовые копии нужны для отладки актуальных данных. Прописанные первоначально тестовые базы не нужны будут со временем.
И не нужно так нервничать. Решать все равно не нам.
Но вся эта фигня со специальными строками запуска - она и есть фигня.
Да да. так и заявите фирме 1С, а то повадились бэкапы скриптами делать :)
(28)
А если каждая копия делается вручную под каждую хотелку конкретного пользователя - ну вот админ, который её сделал - у того точно найдется 2 минуты времени, чтобы либо изменить права, либо прописать базу в настройках.
Как я понимаю, эти тестовые копии нужны для отладки актуальных данных. Прописанные первоначально тестовые базы не нужны будут со временем.
и как это противоречит? Если копии делаются автоматизированно по плану скриптами SQL - то наверняка у них и имена заранее известны и жестко зафиксированы.
А если каждая копия делается вручную под каждую хотелку конкретного пользователя - ну вот админ, который её сделал - у того точно найдется 2 минуты времени, чтобы либо изменить права, либо прописать базу в настройках.
Да да. так и заявите фирме 1С, а то повадились бэкапы скриптами делать :)
Ага. Вот только скрипт бэкапа не запускает некий "заранее внедренный в конфигурацию ключ запуска", а тупо запускает механизм платформы. Он не дает запускающему пользователю несанкционированного доступа к данным.
(30) Ребята, вы лучшие!!!
Вы натолкнули меня на более простое решение!!!
Просто прописать по гуиду нужных мне пользюков админами, если в базе запрещена работа внешних обработок и регл. заданий!
Осталось только получить на это разрешение!
П.С. Я бы даже с удовольствием вам обоим присвоил бы решение, жаль так нельзя!
Вы натолкнули меня на более простое решение!!!
Просто прописать по гуиду нужных мне пользюков админами, если в базе запрещена работа внешних обработок и регл. заданий!
Осталось только получить на это разрешение!
П.С. Я бы даже с удовольствием вам обоим присвоил бы решение, жаль так нельзя!
(30) админ может быть у франча. И не хочет давать права админа сотрудникам предприятия. Или еще по каким причинам.
В любом случае у предприятия/подразделения по факту нет админа пользователя. Некому дать права, иначе и самого вопроса не было бы.
(30)
т.е. когда скрипт дает этот доступ, то это плохо, а если регламентное задание, то все нормально?
(27) По поводу регламентных заданий:
1. Базы на БСП для копии отрубают регламентные задания. Это правильно. Не факт, что пользователи смогут запустить нужное.
2. запуск регламентного задания 1 раз в сутки. Вот зачем это нужно? для постоянно работы лишняя нагрузка. Для копии - слишком большой интервал.
3. и какой текущий пользователь будет во время выполнения регламентного задания? Кому он роли будет прописывать? Всем? А если не нужно всем?
А с этим вообще приходим к тому, с чего и начали: "если нет прав Администрирование, то не даст изменить."
В любом случае у предприятия/подразделения по факту нет админа пользователя. Некому дать права, иначе и самого вопроса не было бы.
(30)
Он не дает запускающему пользователю несанкционированного доступа к данным.
т.е. когда скрипт дает этот доступ, то это плохо, а если регламентное задание, то все нормально?
(27) По поводу регламентных заданий:
1. Базы на БСП для копии отрубают регламентные задания. Это правильно. Не факт, что пользователи смогут запустить нужное.
2. запуск регламентного задания 1 раз в сутки. Вот зачем это нужно? для постоянно работы лишняя нагрузка. Для копии - слишком большой интервал.
3. и какой текущий пользователь будет во время выполнения регламентного задания? Кому он роли будет прописывать? Всем? А если не нужно всем?
Да даже и без регламентного задания - зафигачьте в расширение ПриНачалеРаботыСистемы() эту проверку - да и все.
А с этим вообще приходим к тому, с чего и начали: "если нет прав Администрирование, то не даст изменить."
(33)
Конечно. Потому что внешний скрипт - это внешний файл, который может запустить любой лох. А регламентное задание - это внутренняя сущность 1С, её может настроить только реальный админ, а не лох с дискеткой.
Я где-то настаивал именно на таком интервале? И что за лишняя такая нагрузка на сервер - раз (или несколько) в сутки прочитать настройки из ХранилищеНастроек и сравнить с текущим именем базы?
админ может быть у франча.
После этого вообще стало неинтересно )) Владелец данных, отдающий админский доступ на сторону, и не имеющий к нему доступа... Ну. Помер максим, ну и...
т.е. когда скрипт дает этот доступ, то это плохо, а если регламентное задание, то все нормально?
Конечно. Потому что внешний скрипт - это внешний файл, который может запустить любой лох. А регламентное задание - это внутренняя сущность 1С, её может настроить только реальный админ, а не лох с дискеткой.
запуск регламентного задания 1 раз в сутки. Вот зачем это нужно? для постоянно работы лишняя нагрузка. Для копии - слишком большой интервал.
Я где-то настаивал именно на таком интервале? И что за лишняя такая нагрузка на сервер - раз (или несколько) в сутки прочитать настройки из ХранилищеНастроек и сравнить с текущим именем базы?
Кому он роли будет прописывать? Всем? А если не нужно всем?
Вы хоть бы читали что я писали, прежде чем отвечать. Я же не зря упомянул о форме настройки допобработки, на которой возможно прописывать все необходимые разрешения/ограничения? И про то, что эта форма будет доступна только реальному админу - я же тоже писал, правда?
(40)
Повторю ваши же слова: "Вы хоть бы читали что я писали, прежде чем отвечать."
Какой нафиг внешний файл?
Скрипт формируется внутри модуля как строка.
Точно так же работает и скрипт бэкапа в типовых. Формируется строка запуска пакетного задания вызова конфигуратора с передачей параметров на создание бэкапа средствами конфигуратора.
Потому что внешний скрипт - это внешний файл, который может запустить любой лох
Повторю ваши же слова: "Вы хоть бы читали что я писали, прежде чем отвечать."
Какой нафиг внешний файл?
Скрипт формируется внутри модуля как строка.
Точно так же работает и скрипт бэкапа в типовых. Формируется строка запуска пакетного задания вызова конфигуратора с передачей параметров на создание бэкапа средствами конфигуратора.
(42)
А вы предлагаете использовать при запуске в режиме Предприятия то ли платформенный ключ запуска внешней обработки, то ли использовать кастомизированный ключ запуска от БСП.
Я верно понимаю?
Точно так же работает и скрипт бэкапа в типовых. Формируется строка запуска пакетного задания вызова конфигуратора с передачей параметров на создание бэкапа средствами конфигуратора.
Ага. Вот только ключи конфигуратора жестко регламентированы.
А вы предлагаете использовать при запуске в режиме Предприятия то ли платформенный ключ запуска внешней обработки, то ли использовать кастомизированный ключ запуска от БСП.
Я верно понимаю?
(43) странные выводы.
строка скрипта:
то что передаем в параметре /C будет доступно на клиенте в глобальном контексте ПараметрЗапуска. так можно передать гуид или имя пользователя для последующего использования.
Просто анализируем в обработчике ПередНачаломРаботыСистемы ПараметрЗапуска и если там есть нужные данные проверяем доступность права Администрирование. На основании этого выполняем нужные действия при необходимости и завершаем работу.
В параметр можно передавать любые строковые данные. Можно сформировать строку json, в которой передавать формализованные данные, чтобы быть уверены в результате получения нужных данных.
Все это делается внутри модулей 1С.
строка скрипта:
Скрипт = """C:\Program Files\1cv81\bin\1cv8.exe"" ENTERPRISE /F""D:\1C_base\ZUPRAZR"" /N""Админ"" /P""12345"" /C""тутГуид""";то что передаем в параметре /C будет доступно на клиенте в глобальном контексте ПараметрЗапуска. так можно передать гуид или имя пользователя для последующего использования.
Просто анализируем в обработчике ПередНачаломРаботыСистемы ПараметрЗапуска и если там есть нужные данные проверяем доступность права Администрирование. На основании этого выполняем нужные действия при необходимости и завершаем работу.
В параметр можно передавать любые строковые данные. Можно сформировать строку json, в которой передавать формализованные данные, чтобы быть уверены в результате получения нужных данных.
Все это делается внутри модулей 1С.
(44)
Так я об этом и говорю: если знаешь незащищенный ключ запуска, то получаешь админский доступ ко всем данным.
Или вы думали, что я тут спорю про техническую сторону вопроса???
Просто анализируем в обработчике ПередНачаломРаботыСистемы ПараметрЗапуска и если там есть нужные данные проверяем доступность права Администрирование. На основании этого выполняем нужные действия при необходимости и завершаем работу.
Так я об этом и говорю: если знаешь незащищенный ключ запуска, то получаешь админский доступ ко всем данным.
Или вы думали, что я тут спорю про техническую сторону вопроса???
(1) задача выеденного яйца не стоит... ИМХО
если тестовая база = еженочный бекап, то надо просто в батник, который делает бекап,
добавить запуск обработки, которая делать права тем кому надо. при каждом делании бекапа
и всё.
PS обработка запускается с правами того, кто имеет права это сделать, а тем кому это надо сделать.
если тестовая база = еженочный бекап, то надо просто в батник, который делает бекап,
добавить запуск обработки, которая делать права тем кому надо. при каждом делании бекапа
и всё.
PS обработка запускается с правами того, кто имеет права это сделать, а тем кому это надо сделать.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот