Тестирование прав пользователей. DAX 4.0.

[sukhanchik]

Навеяло этой темой. Решил выложить модификацию сей утилиты (да простят меня ее авторы, что я ее немного переработал)
Исходная версия утилиты работала следующим образом:
1. Подменялся SID у нужного пользователя
2. Запускалась новая Аксапта с параметром /WAIT, т.е. исходное приложение ожидало завершение нового приложения
3. SID менялся обратно.

У данного алгоритма есть 2 существеных недостатка.
1. Если что-то где-то как-то сбойнет и исходное приложение вылетит до завершения нового, то потом придется ручками в БД возвращать на место SIDы
2. Как показала практика - не стоит трогать SID у пользователя Admin, т.к. это может привести к результатам из п.1

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

В связи с этим - алгоритм изменился на следующий:
1. Идет проверка на запрет запуска утилиты из под Admin-а и от имени Admin-а
2. Подменяется SID у тестируемого пользователя (как было)
3. Если Аксапта запускалась через конфигурационный файл (в командной строке был указан axc-шник) - то новая Аксапта запускается с этим же конфигурационным файлом. Если конфигурационного файла не было - то Аксапта запускается с тем же портом, что и исходная, но в usr-слое и другими параметрами по умолчанию. Аксапта запускается без параметра WAIT, т.е. исходное приложение не ожидает завершения нового.
4. После запуска новой Аксапты исходная система "ловит" новую запись этого SIDа, сделанную в таблице SysClientSessions. В процессе "ловли" она ждет 10 секунд появления этой записи. Если не дожидается - то выдает запрос - "Подождать/Отменить?", после чего либо снова ждет, либо возвращает SIDы на место. В любом случае - либо после отмены в запросе, либо после перехвата записи - исходный SID возвращается на место.

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

Ну и конечно все вынесено в отдельную кнопку, которая вешается на стандартную форму SysUserInfo (\Администрирование\Пользователи).

[Link]

Цитата:

Сообщение от sukhanchik

Навеяло этой темой. Решил выложить модификацию сей утилиты (да простят меня ее авторы, что я ее немного переработал)
Исходная версия утилиты работала следующим образом:
1. Подменялся SID у нужного пользователя
2. Запускалась новая Аксапта с параметром /WAIT, т.е. исходное приложение ожидало завершение нового приложения
3. SID менялся обратно.

У данного алгоритма есть 2 существеных недостатка.
1. Если что-то где-то как-то сбойнет и исходное приложение вылетит до завершения нового, то потом придется ручками в БД возвращать на место SIDы
2. Как показала практика - не стоит трогать SID у пользователя Admin, т.к. это может привести к результатам из п.1

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

В связи с этим - алгоритм изменился на следующий:
1. Идет проверка на запрет запуска утилиты из под Admin-а и от имени Admin-а
2. Подменяется SID у тестируемого пользователя (как было)
3. Если Аксапта запускалась через конфигурационный файл (в командной строке был указан axc-шник) - то новая Аксапта запускается с этим же конфигурационным файлом. Если конфигурационного файла не было - то Аксапта запускается с тем же портом, что и исходная, но в usr-слое и другими параметрами по умолчанию. Аксапта запускается без параметра WAIT, т.е. исходное приложение не ожидает завершения нового.
4. После запуска новой Аксапты исходная система "ловит" новую запись этого SIDа, сделанную в таблице SysClientSessions. В процессе "ловли" она ждет 10 секунд появления этой записи. Если не дожидается - то выдает запрос - "Подождать/Отменить?", после чего либо снова ждет, либо возвращает SIDы на место. В любом случае - либо после отмены в запросе, либо после перехвата записи - исходный SID возвращается на место.

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

Ну и конечно все вынесено в отдельную кнопку, которая вешается на стандартную форму SysUserInfo (\Администрирование\Пользователи).

Спасибо!
Обновил для 2009 версии. Тестировалось на SP1 RU7.

[kalex]

Тот же самый проект, перенесенный на AX 2012.

[Oz]

Цитата:

Сообщение от kalex

Тот же самый проект, перенесенный на AX 2012.

Коллеги! А есть ли у кого-нибудь положительный опыт использования это утилиты на DAX 2012?
Как я вижу, сессия под другим пользователем запускается. Однако, так как непосредственно после её старта запускающая сессия должна возвращать SID'ы пользователей на место, запущенная сессия оказывается нежизнеспособна - любые попытки что то открыть на ней приводят к немедленному падению.
Удалось ли кому-нибудь побороть этот эффект и таки воспользоваться этой полезной фичей?