Кто автор этого "гениального" кода?

[glibs]

\Data Dictionary\Maps\CustVendTable\Methods\balanceAllCurrency()

//BP Deviation Documented
display AmountCur balanceAllCurrency(CurrencyCode _currencyCode = this.Currency)
{
...
    switch (custVendTrans.TableId)
    {
        case tablenum(CustTrans) :
            hasAccess = hasFieldAccess(tablenum(CustTrans), fieldnum(CustTrans, AmountCur), AccessType::View);
            hasAccess = hasAccess && hasFieldAccess(tablenum(CustTrans), fieldnum(CustTrans, AmountMST), AccessType::View);
            hasAccess = hasAccess && hasFieldAccess(tablenum(CustTrans), fieldnum(CustTrans, ExchAdjustment), AccessType::View);
            break;

        case tablenum(VendTrans) :
            hasAccess = hasFieldAccess(tablenum(VendTrans), fieldnum(VendTrans, AmountCur), AccessType::View);
            hasAccess = hasAccess && hasFieldAccess(tablenum(VendTrans), fieldnum(VendTrans, AmountMST), AccessType::View);
            hasAccess = hasAccess && hasFieldAccess(tablenum(VendTrans), fieldnum(VendTrans, ExchAdjustment), AccessType::View);
            break;
    }

    if (!hasAccess)
        throw error("@SYS57330");
...

Нельзя в display-методе "0.00" вернуть, если нет доступа, вместо выброса исключения? Я уж молчу про информативность сообщения "Нет доступа".

[pitersky]

Цитата:

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

Нельзя в display-методе "0.00" вернуть, если нет доступа, вместо выброса исключения? Я уж молчу про информативность сообщения "Нет доступа".

Вот я бы, увидев ноль в форме/отчёте, принял бы его за результат вычислений, но никак не за проблему прав доступа. Так что с этой точки зрения всё логично. Другое дело, что вешать такую проверку именно на дисплей - мегастранно. Я бы сначала проверил права человека на доступ к объекту, и если они есть - строил бы без всяких исключений.

Цитата:

Я бы сначала проверил права человека на доступ к объекту

а одно другому не мешает. А вот если секретные данные сольются - будет потеха...

[pitersky]

Цитата:

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

а одно другому не мешает

А по-моему - очень даже мешает.
Т.е. если у человека нет прав на просмотр поля репорта - надо просто скрыть это поле и всё. Дисплей-то здесь причём?

[glibs]

Цитата:

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

...
Вот я бы, увидев ноль в форме/отчёте, принял бы его за результат вычислений
...

А вот я бы на вашем месте так поступать в общем случае не стал.

Если поле рассчитано по query, а в query не отключен RLS принудительно в коде, то результат расчета будет зависеть от настроек RLS. В Аксапте есть ряд таких мест.

Цитата:

если у человека нет прав на просмотр поля репорта

Цитата:

\Data Dictionary\Maps\CustVendTable\

при чем здесь репорт? метод - как метод. вызывается отовсюду. И, самое главное, при драг-н-дропе с одного объекта на другой Ваша проверка быстро исчезнет. А проверка внутри метода - никогда.

Цитата:

Если поле рассчитано по query

это вообще как сюда относится?

[S.Kuskov]

Видеть ноль вместо скрытого столбца - не правильно. Видеть столбец, который должен быть скрыт - не допустимо. Исключение, которое выдаётся в display методе - это фол последней надежды. Сообщение предназначено не для пользователя, а для программиста, который забыл разрулить права на уровне дизайна.

P.S.: Очень к стати в таких случаях было бы задействовать nullable тип. Жаль что в аксапте нет такой возможности. .

[gl00mie]

А каким образом, если не секрет, применительно к этому display-методу мог бы помочь nullable-тип? Отображать в FormRealControl null вместо числа?..

вроде только что обсудили, что такое //BP Deviation Documented и то, что проверки на доступ к дисплей-эдит методам теперь по БП ДОЛЖНЫ быть...

[glibs]

Должнны быть. Однозначно.

Остался вопрос какими они должны быть.

[S.Kuskov]

Цитата:

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

Отображать в FormRealControl null вместо числа?..

Не всегда выбрасывать исключение удобно. Подход с отображением вместо скрытых данных заглушки (будь то ноль или null) позволяет отображать результаты сложных display методов, доступ к данным которых может быть различным в рамках одной выборки. Т.е. в одном и том же столбце грида могут быть выведены доступные для просмотра данные и null'ы вместо скрытых

Как по мне, так null лучше, чем двусмысленный ноль. Также если это null значение вдруг будет использоваться дальше для дальнейших вычислений, то логично ожидать в результате тоже null (в варианте с нулём может получиться неполноценное выражение, которое может ввести пользователя в заблуждение).

Лучше конечно заложить в систему два режима работы - отображать null либо генерить исключение (что-то вроде свойства allowNull на контроле). Чтобы в каждом конкретном случае можно было бы вибирать наиболее ожидаемое поведение.

[Волчара]

Цитата:

Сообщение от S.Kuskov

Видеть ноль вместо скрытого столбца - не правильно. Видеть столбец, который должен быть скрыт - не допустимо. Исключение, которое выдаётся в display методе - это фол последней надежды. Сообщение предназначено не для пользователя, а для программиста, который забыл разрулить права на уровне дизайна.

P.S.: Очень к стати в таких случаях было бы задействовать nullable тип. Жаль что в аксапте нет такой возможности. .

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

Кстати throw error() как сообщение для разработчика в дисплей методе весьма не удобно, т.к. из формы уже не выйдешь - приходится три пальца в рот....

throw error() - (генерация исключения) - это ОТКАЗ В ОБСЛУЖИВАНИИ и никакими "0.00", "null" и проч. заменен быть не может.

Зацикливание дисплей-методов на контролах в таком случае - это косяк. Но это к теме не относится.

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

Если уж хотите реально вменяемые сообщения - нужно переписывать их все, чтоб не выбивалось.

[glibs]

Цитата:

Сообщение от S.Kuskov

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

Не хотелось бы в данный ммоент вдаваться в технические детали, но на практике данный подход, похоже, не сработал. У разработчика в системе обычно административные права. И подобного рода ошибки он не отслеживает.

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

Для меня тема интересна в следующем ключе. Раньше были display-методы (edit-методы потом появились на их подобии). Потом этот контрол был признан опасным с т.з. безопасности. Пришлось писать "// BP deviation documented". Некоторые вот идут дальше. И не всегда удачно. Для меня не до конца понятно какой сегодня ВР по использованию display-методов.

...

Подумал. Вот нашел.

"
Using Display and Edit methods
When you use a display or edit method, consider using record-level security if a value is returned from another row.
However, record-level security is not required in these situations:
• If the value is derived.
• If the value is based only on fields in the current record.
"

"
Display and Edit Methods

You can enforce security on display or edit methods on forms (but not on reports) when the method is declared on the table in the AOT.
In practice, if a user has access to a table, the user also has access to all of the display methods (from reports).

In theory, a display method can expose any data from any table. If a display method returns data from another table (or another row in the same table), it poses a threat.

The following examples illustrate these vulnerabilities.
Example (Table: InventItemGroup)

display ForecastHasSales hasSalesBudget()
{
    return (select forecastSales
                where forecastSales.itemGroupId == this.itemGroupId).recId != 0;
}

Example (Table: CustInterestJour)

server display InterestAmountCur sumInterestAmount()
{
    InterestAmountCur   interestAmountCur;
    CustInterestTrans   custInterestTrans;

    while select sum(InterestAmount) from custInterestTrans
        group by CurrencyCode
        where custInterestTrans.InterestNote == this.InterestNote &&
              custInterestTrans.InterestCalculate
    {
        interestAmountCur += custInterestTrans.custInterestAmount(this);
    }
    return interestAmountCur;
}

Before taking action, consider each situation carefully. In many cases, the information is derived and therefore does not pose any threat.

If a display method returns data from the same row but from another column, it also poses a threat. For example, a user may not be allowed to see another person’s monthly salary, but could run a query to ask for the annual salary (calculated value).

Mitigation

To mitigate threats associated with the use of display and edit methods, follow these steps:
1. Evaluate each display method that returns data from another row, either in the same table or a different table.
2. Discuss (internally) if this data poses an information-disclosure threat.
3. If the data does pose a threat, perform explicit authorization checks, and throw an exception if access is unauthorized.
"
Надергано из документа "Microsoft Dynamics AX 4.0 Writing Secure X++ Code".

Кстати приведенный мною в первом посте пример как раз соответствует рекомендациям .

Только как-то некрасиво получается в плане usability. Это сообщение для кого? Если для того кто настраивает права — то было бы удобнее без exception. Ну и с более внятным сообщением об ошибке.

Вообще с настройкой дотупа на контролы в форме на display-методах всегда были проблемы. Посидишь, настроишь. Разработчик пошевелит дизайн формы — высока вероятность что настройки слетят. Сидишь потом как дурачок восстанавливаешь везде.

В общем, ожидалось удобное решение, а не такое вот...

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

Потому про удобство нужно забыть. Радуйтесь, что решаются вопросы с надежностью.