Використання атрибутів безпеки для контролю доступу до коду, блог імені очкарика

Ось.
Далі, з точки зору моделі безпеки .NET роль є рядком. Не будемо сперечатися з розумними дядьками в окулярах з Microsoft, рядок так рядок:

Зверніть увагу, рядки оголошені в якості констант; трохи пізніше я поясню, навіщо це потрібно.
До речі, більше ніякі допоміжні класи не знадобляться, можна переходити до розгляду власне програми. Я накидав консольний додаток, щоб не мудрувати лукаво: для демонстрації прототипу, в общем-то, зійде. Ця програма показує, як саме виглядає використання атрибута PrincipalPermission в коді, і подальші словеса тут, в общем-то, зайві:

Що ж, подивимося, що вийшло:

Реальна поведінка відповідає очікуваному. Схоже, все працює. Надійно, красиво, легко використовувати. Ліпота.

PS Ах да, я забув пояснити, навіщо робити рядки константними. Якщо цього не зробити - компілятор не зможе зібрати програму, лаючись вкрай невиразним чином:

Щодо констант в параметрах конструктора атрибута: метадані атрибутів збираються під час компіляції, тому його параметри повинні бути константами часу компіляції. Ну ще можуть бути typeof () виразами або масивом констант часу компіляції.

А ще цікавий момент щодо атрибутів: конструктор атрибута викликається тільки при спробі отримати його. Так що якщо в тілі конструктора є перевірка аргументу з викиданням ArgumentException, то випаде ця радість виключно в Рантайм, але не при компіляції (а шкода, іноді було б корисно)

Ну да, може, я й погарячкував щодо невиразності лайки, але як на мене - все одно оприлюднення вимог без натяку на пояснення причин виглядає якось ... хоча так, що з компілятора взяти-то, все нормально.

Що стосується конструктора атрибута - мені здається, такий пристрій дає більше можливостей: зокрема, конструктор має можливість враховувати рантайм-контекст, що, зрозуміло, неможливо на стадії компіляції. Конструювати атрибути на стадії компіляції було б в окремих випадках, напевно, зручніше, але мені здається, що ціна виявилася б занадто висока.

Схожі статті