|
![]() |
#1 |
Member
|
Цитата:
Сообщение от 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) X++: display ForecastHasSales hasSalesBudget() { return (select forecastSales where forecastSales.itemGroupId == this.itemGroupId).recId != 0; } X++: 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; } 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-методах всегда были проблемы. Посидишь, настроишь. Разработчик пошевелит дизайн формы — высока вероятность что настройки слетят. Сидишь потом как дурачок восстанавливаешь везде. В общем, ожидалось удобное решение, а не такое вот...
__________________
С уважением, glibs® |
|
|
За это сообщение автора поблагодарили: S.Kuskov (1). |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|