Как правильно создавать новые и использовать существующие SecurityKey

[Ivanhoe]

Цитата:

Сообщение от Владимир Максимов

Нет. Мне нужны не "общие слова", а именно те два простых правила, которые я и привел как тот принцип, по которому работают участники данной темы.

1. На сам Security Keys не дается вообще никаких прав. Полный запрет. Уровень доступа = "Нет доступа"
2. Права даются на объекты, подключенные к соответствующему Security Keys

Так вот, ЭТИХ правил в приведенных описаниях нет.

Цитата:

Approaches to Granting Security
There are a few things to consider when approaching security. For some it is best to begin with the highest permissions level and restrict access to specific objects. For others, it is best to begin with the lowest level and grant access to objects. The best approach may vary for each user group.

The advantage to starting will the highest level and then restricting specific objects is that it leaves permission granted to the parent keys, such as the “Accounts Receivable” key. On its own, this key grants nothing to a user that they can see in the application, but for some operations the inherited pieces may be necessary.

Alternatively, starting with the least access and granting has the advantage of keeping the application as locked down as possible. The disadvantage here is that when a parent key is needed, it must be turned on. This will grant access to all child keys. This means that you must go back and restrict access again, and essentially doubles the effort in a case that the need for a parent key is found.

...

Т.е. многие (в т.ч. я) идут по второму пути - более строгому и защищенному. Но есть более простой способ (и многие идут именно по нему) - давать права от ключей.

[Ivanhoe]

Цитата:

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

Продолжаем...
На Ax2009 RU6
Из этого видно, что право на картотеку номенклатуры у пользователя есть,
однако добавить эту таблицу в настройку фильтра в форме "заказы" он не может.

А у пользователя есть права на таблицу xRefTableRelation??

[someOne]

Цитата:

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

А у пользователя есть права на таблицу xRefTableRelation??

В этом случае как раз права на таблицу xRefTableRelation ничего не дадут.
Даже если вы откроете права на эту таблицу то при попытке пользователем открыть диалог добавления таблицы в источник данных получите сообщение как показано ниже. Поэтому решить проблему может лишь открытие права целиком на ключ SysDevelopmentTables, либо отключение свойства AOSAuthorization таблицы xRefTableRelation с CreateReadUpdateDelete на None. Это сделано. И этого не достаточно.

Вне зависимости от варианта решения, пользователь все равно "видит" не все таблицы, а только те, на которых вообще нет никакого ключа, либо те таблицы, на ключ которых он имеет право, но не на объект (таблицу).

Проверил еще раз на НЕ модифицированном приложении ax2009 ru6

[Владимир Максимов]

Цитата:

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

Approaches to Granting Security
(...)

А это откуда цитата?

PS: Извините, уже нашел. Это из MicrosoftDynamicsAX2009Security.pdf "Understanding Security in Microsoft Dynamics AX 2009"

[Ivanhoe]

Цитата:

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

В этом случае как раз права на таблицу xRefTableRelation ничего не дадут.
Даже если вы откроете права на эту таблицу то при попытке пользователем открыть диалог добавления таблицы в источник данных получите сообщение как показано ниже. Поэтому решить проблему может лишь открытие права целиком на ключ SysDevelopmentTables, либо отключение свойства AOSAuthorization таблицы xRefTableRelation с CreateReadUpdateDelete на None. Это сделано. И этого не достаточно.

Проверил еще раз на НЕ модифицированном приложении ax2009 ru6

Не понял =). Если прав на таблицу xRefTableRelation нету - то все ок, а если есть - то выдается ошибка??

И по логике, и по факту на моей модифицированной, но не в части прав AX, всё наоборот - если прав на эту таблицу нет (не на ключ, а на таблицу), то ошибка выдается. Если права дать - то всё работает.

Как-то уж очень по-разному ведет себя аксапта в наших инсталляциях. Надо проверить у кого-то еще!

[someOne]

Цитата:

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

Не понял =). Если прав на таблицу xRefTableRelation нету - то все ок, а если есть - то выдается ошибка??

И по логике, и по факту на моей модифицированной, но не в части прав AX, всё наоборот - если прав на эту таблицу нет (не на ключ, а на таблицу), то ошибка выдается. Если права дать - то всё работает.

Как-то уж очень по-разному ведет себя аксапта в наших инсталляциях. Надо проверить у кого-то еще!

Видимо я выразился не слишком ясно.

Суть того, что я хотел сообщить, в следующем:
1. Права на таблицу xRefTableRelation, конечно же есть. Если бы их не было - то выдавалась бы ошибка о том что нет доступа (которую я привел), а не выдавался бы список "пусто" на сером фоне.

2. Этих прав (на таблицу xRefTableRelation) не достаточно. Для того чтобы в списке появились необходимые таблицы - приходится открывать пользователю права на ключи таблиц. Если этого не делать - в списке отображаются только таблицы БЕЗ ключей


Не поленился разобраться, в чем же "засада".

Все дело в методе класса
\Classes\SysQueryBuilder\buildRelations
Там есть такой метод, который определяет "доступна" ли таблица данному пользователю

Если на таблице есть какой нибудь ключ безопасности, и у пользователя нет прав на этот ключ, (хотя и есть право на объект (таблицу)) то при запуске проверка возвращает "false", поэтому таблицы и не отражаются пользователю.

private static client server Map buildRelations(Map _map, SysDictTable _orgDictTable, TableName _tableName, RelationName _relationName)
.....
    if (dictTable &&
        dictTable.rights() > AccessType::NoAccess &&
        !dictTable.isTmp())
    {

Особенность в том что в случае запуска на стороне сервера и на стороне клиента (у меня по крайней мере) он возвращает разные значения!!!

Вот пример. Проверьте у себя разве он у вас работает не так ?

static void test(Args _args)
{
    SysDictTable    DictTable;
    ;
  
    dictTable   = new SysDictTable(tablename2id("SalesLine"));

    if (dictTable.rights() > AccessType::NoAccess)
    {
        info("true");
    }
    else
    {
        info("fasle");
    }
}

Если на таблице есть какой нибудь ключ безопасности, и у пользователя нет прав на этот ключ, но есть право на объект (таблицу), то при запуске на стороне сервера пример вернет "false", а при запуске на клиенте - "true"

В этом кажется, и есть проблема.

Интересно, каким образом в вашем случае пользователю отображены табличные связи ? Неужели в вашем случае этот метод работает иначе ???

Кстати проблема решается если в классе SysQueryBuilder вместо
private static server container findRelations(tableId _tableId)
написать
private static client container findRelations(tableId _tableId)

[Ivanhoe]

Цитата:

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

Если на таблице есть какой нибудь ключ безопасности, и у пользователя нет прав на этот ключ, (хотя и есть право на объект (таблицу)) то при запуске проверка возвращает "false"

Почему сделан такой вывод? =) Так должно быть согласно документации? По мне (я не программист, могу и заблуждаться), dictTable.rights() должен возвращать доступ к объекту, а не его ключу. Ведь проверка на доступ к ключу обычно делается по-другому.

Цитата:

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

Особенность в том что в случае запуска на стороне сервера и на стороне клиента (у меня по крайней мере) он возвращает разные значения!!!

Вот пример. Проверьте у себя разве он у вас работает не так ?

Если на таблице есть какой нибудь ключ безопасности, и у пользователя нет прав на этот ключ, но есть право на объект (таблицу), то при запуске на стороне сервера пример вернет "false", а при запуске на клиенте - "true"

Интересно, каким образом в вашем случае пользователю отображены табличные связи ? Неужели в вашем случае этот метод работает иначе ???

У меня в дебагере стоит значек "сервера" напротив метода \Classes\SysQueryBuilder\buildRelations - значит выполняется на сервере? Джоб запускал и напрямую, и через меню айтем с запуском на сервере - в обоих случаях возвращает true.

Явно же барабашки нет? ) Не знаю, важно это или нет, но клиент стоит на самом сервере АОС.