Система безопасности на основе ОС

[developer]

Доброе время суток!

Изучаю возможности классического InTouch 9.5 при использовании системы безопасности на основе операционной системы. Использую функцию AddPermission, чтобы задать права для определённой группы пользователей (другого пути нет, кстати?).
В документации написано следующее "Этот список, созданный после выполнения вызова скрипт-функции AddPermission(), записывается на диск. Файл, содержащий аутентификационные сведения о пользователях, копируется на клиентские узлы NAD"
Было замечено, что при использовании этой функции в папке проекта ведётся файл AuthHist.xml, в котором содержится история аутентификации. Однако при перезапуске WindowViewer все назначенные мною права теряются и все группы пользователей имеют AccessLevel = 0. Возможно ли на самом деле сохранение списка пользователей с соответствующими права между перезапусками WindowViewer?

[Генератор зла]

Доброе время суток!

Изучаю возможности классического InTouch 9.5 при использовании системы безопасности на основе операционной системы. Использую функцию AddPermission, чтобы задать права для определённой группы пользователей (другого пути нет, кстати?).
В документации написано следующее "Этот список, созданный после выполнения вызова скрипт-функции AddPermission(), записывается на диск. Файл, содержащий аутентификационные сведения о пользователях, копируется на клиентские узлы NAD"
Было замечено, что при использовании этой функции в папке проекта ведётся файл AuthHist.xml, в котором содержится история аутентификации. Однако при перезапуске WindowViewer все назначенные мною права теряются и все группы пользователей имеют AccessLevel = 0. Возможно ли на самом деле сохранение списка пользователей с соответствующими права между перезапусками WindowViewer?

Если не ошибаюсь, файл должен быть Password.bin

[Spaun]

AddPermission() должна вызываться при запуске приложения.
Для последующей идентификации используете функцию LogonCurrentUser() ?

[developer]

Если не ошибаюсь, файл должен быть Password.bin

Я проделал такой опыт. Поставил в WindowMaker Security Type = OS. На экране сделал кнопку с вызовом функции AddPermission, которая добавляет группе "Пользователи" уровень доступ 2000. После запуска WindowView я эту кнопку нажал, права добавились, в режим исполнения всё работает как надо. Но содержимое файла Password.bin при этом не меняется и при перезапуске WindovView уровень доступа отказывается нулевой. Единственное что меняется, это содержимое файла AuthHist.xml

AddPermission() должна вызываться при запуске приложения.
Для последующей идентификации используете функцию LogonCurrentUser() ?

Использую функцию AttemptInvisibleLogon

[Генератор зла]

Если не ошибаюсь, файл должен быть Password.bin

Я проделал такой опыт. Поставил в WindowMaker Security Type = OS. На экране сделал кнопку с вызовом функции AddPermission, которая добавляет группе "Пользователи" уровень доступ 2000. После запуска WindowView я эту кнопку нажал, права добавились, в режим исполнения всё работает как надо. Но содержимое файла Password.bin при этом не меняется и при перезапуске WindovView уровень доступа отказывается нулевой. Единственное что меняется, это содержимое файла AuthHist.xml

AddPermission() должна вызываться при запуске приложения.
Для последующей идентификации используете функцию LogonCurrentUser() ?

Использую функцию AttemptInvisibleLogon

Может это поможет?
Issue Summary: When configuring OS Type Security, the new setting is not retained.
Resolution: The workaround for this issue is to check Show Application Directory in the WindowMaker configuration, restart WindowMaker, then reconfigure the Security type. Then the SecConfig.xml, AuthHist.xml files should be created/updated.

[developer]

Может это поможет?
Issue Summary: When configuring OS Type Security, the new setting is not retained.
Resolution: The workaround for this issue is to check Show Application Directory in the WindowMaker configuration, restart WindowMaker, then reconfigure the Security type. Then the SecConfig.xml, AuthHist.xml files should be created/updated.

Поигрался с галочкой Show Application Directory, не помогло. Будем использовать Security Type = InTouch, эта часть работает как положено.

[Генератор зла]

Может это поможет?
Issue Summary: When configuring OS Type Security, the new setting is not retained.
Resolution: The workaround for this issue is to check Show Application Directory in the WindowMaker configuration, restart WindowMaker, then reconfigure the Security type. Then the SecConfig.xml, AuthHist.xml files should be created/updated.

Поигрался с галочкой Show Application Directory, не помогло. Будем использовать Security Type = InTouch, эта часть работает как положено.

Проверьте, установлен ли SP1 для InTouch 9.5. Это последнее обновление для данной версии.

[developer]

Проверьте, установлен ли SP1 для InTouch 9.5. Это последнее обновление для данной версии.

Дистрибутив был сразу Wonderware InTouch 9.5 with SP1

[Basilio]

Issue Summary: AddPermission() does not seem to work the first time it is used; $AccessLevel of the operator logged on to InTouch did not change.

Cause Description: THIS BEHAVIOR WORKS AS DESIGNED (WAD). The issue was reviewed and it was determined that the product was intentionally designed to behave in the manner described within the issue.

Resolution Summary: AddPermission() should be used before logging on a user that is a member of the affected group.

ISSUE: $AccessLevel is not updated on first login:
My application wants the operator to login/logout with a logged reason and to use the Windows 2000 security accounts on the HMI computer. I have a logon screen that lists the reasons in a combo box and then shows the login/logout button once a reason is selected. This button exectutes PostLogonDialog(). While the logon screen is running, every 250ms a script runs that uses AddPermission() and uses the current login information from PostLogonDialog().

We know that AddPermission() changes the $AccessLevel to whatever is written in its statement. However, at the first login of the system, AddPermission() doesn't seem to work and change the $AccessLevel. PostLogonDialog() does seem to work because the $Operator and $OperatorDomain are updated with the current information. When I logoff and log back in, the AddPermission() script does work and the $AccessLevel does change. Why doesn't it work during the first login? Please advise.
Development system: Win2KPro, WW8.0 SP2

SOLUTION: Do the AddPermission() before logging on a user in the affected group.

If a user is already logged in to InTouch, and I then use AddPermission() to assign an access level to the user's group, the $AccessLevel does not change. If I login again as the same user, the $AccessLevel does change. If I do the AddPermission() before logging in a user, the $AccessLevel updates as expected.

This is working as designed. From the InTouch Reference Guide:

Valid for OS security mode only. An attempt is made to reach the account Account located on domain Domain. If successful, a TRUE is returned and the access level iAccessLevel is assigned to the account in the internal records in InTouch for use during authorization when a user logs on. In all other cases, a FALSE is returned.
Here are two workarounds:
1. (Preferred) Either do the AddPermission() on application startup (before any user has logged in), or
2. Right after the AddPermission(), check if the currently logged on user is a member of the group that the permission was added to; in which case have the user logon again if the $AccessLevel doesn't match up.

For example:

DIM result AS INTEGER;
DIM domain AS MESSAGE;
DIM group AS MESSAGE;
DIM perm AS INTEGER;
domain = "MYDOMAIN";
group = "MyGroup";
perm = 9000;
msg = ""; {message tag that's displayed on the window}

result = AddPermission( domain, group, perm );
IF result == 1 THEN
result = QueryGroupMembership( domain, group ); {check if the currently logged on user is a member of the group}
IF result == 1 AND $AccessLevel <> perm THEN
msg = "Please logon again.";
result = PostLogonDialog();
ENDIF;
ENDIF;