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

[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-методах всегда были проблемы. Посидишь, настроишь. Разработчик пошевелит дизайн формы — высока вероятность что настройки слетят. Сидишь потом как дурачок восстанавливаешь везде.

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