Написание настраиваемого атрибута на C #, такого как атрибут авторизации ASP.Net MVC

Мне нравится атрибут ASP.Net MVC Authorize, я могу расширить его, построить свою собственную логику и украсить им свой контроллер. НО,

В моей архитектуре у меня есть один общий уровень обслуживания (библиотека классов C #). Конечный пользователь может получить доступ к моему приложению через веб-сайт ASP.Net MVC или через мой открытый уровень REST WCF Webservice. Мое приложение asp.net MVC и уровень сервиса REST WCF, в свою очередь, получают доступ к моему общему уровню сервиса.

Я хочу, чтобы авторизация происходила на этом общем уровне службы, а не в контроллере ASP.Net MVC или на моем открытом уровне службы REST.

Могу ли я создать атрибут авторизации ASP.Net MVC как вещь, чтобы украсить мои методы в общей библиотеке классов C #? Этот атрибут примет параметры и решит, имеет ли текущий пользователь доступ для выполнения этой функции или нет?

С уважением и уважением, Аджай


c# asp.net-mvc attributes wcf
person Ajay    schedule 29.07.2009    source источник

Ответы (4)


arrow_upward
5
arrow_downward

То, что вы ищете, может быть достигнуто с помощью библиотеки AOP, например PostSharp (http://www.postsharp.org/ < / а>). Это сложнее, чем использование атрибута Authorize в mvc, но все же довольно просто.

person maciejkow    schedule 29.07.2009
comment
большое спасибо. PostSharp выглядит хорошо. Я копаюсь в этом прямо сейчас. Надеюсь, моя архитектура получит хороший импульс. - person Ajay; 29.07.2009

arrow_upward
3
arrow_downward

Другой способ справиться с этим - использовать атрибут [PrincipalPermission] на уровне обслуживания. Это может помешать вызывающим объектам выполнить метод (или получить доступ ко всему классу) без определенной авторизации.

person Wyatt Barnett    schedule 29.07.2009

arrow_upward
1
arrow_downward

Нет, AuthorizeAttribute работает, потому что инфраструктура MVC явно вызывает его перед вызовом метода. Аналогичная функция для вашего уровня обслуживания будет работать только в том случае, если ваши клиенты также явно вызвали ее. Было бы неразумно предполагать, что даже благонамеренный клиент всегда будет помнить, что нужно искать атрибут и вызывать его. WCF имеет собственную безопасность. Вы должны использовать это вместо того, чтобы писать свои собственные.

person Craig Stuntz    schedule 29.07.2009
comment
Если я помещу логику авторизации в свои REST API, мне придется дублировать ее и в контроллерах. Вот почему мне нужно сделать что-то, что находится на уровне обслуживания (не WCF, а просто библиотека классов С #) - person Ajay; 29.07.2009
comment
Вам не нужно ничего дублировать. WCF и ASP.NET сообщают вам, кто подключен. Вам просто нужно перевести это в то, что они могут сделать. Этим кодом можно поделиться. Вы просто не должны делать этого с настраиваемым атрибутом - это все, что я говорю. Используйте то, что уже встроено в фреймворки. - person Craig Stuntz; 29.07.2009
comment
Что, если он решит добавить еще один интерфейс? Ему придется снова написать все эти атрибуты. Что, если он изменит некоторые правила, например, каким группам разрешено вызывать метод? Ему придется изменить все свои интерфейсы. Существует возможность создать такой атрибут (с помощью aop), и я считаю, что Аджай должен это сделать, потому что только так он может гарантировать, что авторизация согласована для всех интерфейсов и что он может безопасно добавить еще один интерфейс и не заботиться о вся эта авторизация, общая для всех интерфейсов ... - person maciejkow; 29.07.2009
comment
maciejkow: Я не предлагал использовать атрибуты. Я предложил использовать встроенное управление идентификацией с общим ›кодом идентификационных прав. Если вы думаете, что я предлагал написать что-либо более одного раза, пожалуйста, перечитайте то, что я написал. - person Craig Stuntz; 29.07.2009

arrow_upward
0
arrow_downward

Это не должно быть слишком сложно - есть несколько мест, где вы можете отразить атрибут и обработать его соответствующим образом:

  • При запуске приложения в Global.asx вы можете настроить маршрутизацию и расположение представлений.

  • Базовые события запроса ASP.Net по-прежнему срабатывают, поэтому вы можете переопределить одно из них.

  • Создайте свой собственный базовый контроллер и замените OnActionExecuting

Обновить следующий комментарий

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

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

Если вы не используете отражение для извлечения классов или вызова методов (что, по сути, то, что делает маршрутизация в MVC), то у вас не будет возможности проверить свои атрибуты.

person Keith    schedule 29.07.2009
comment
в ASP.Net MVC я могу это сделать, мне нужно сделать то же самое в библиотеке классов C #, так что любой, кто вызывает метод C #, должен выполнять проверку авторизации. Спасибо. - person Ajay; 29.07.2009