Zapisywanie niestandardowego atrybutu w C# jak ASP.Net MVC Autoryzuj atrybut

Question

Podoba mi się atrybut Authorize ASP.Net MVC, mogę go rozszerzyć i zbudować własną logikę i udekorować nią swój kontroler. ALE,

W mojej architekturze mam jedną wspólną warstwę usług (biblioteka klasy C#). Użytkownik końcowy może uzyskać dostęp do mojej aplikacji za pośrednictwem strony internetowej ASP.Net MVC lub za pośrednictwem mojej odsłoniętej warstwy usługi REST WCF Webservice. Moja aplikacja asp.net MVC i warstwa usługi WCF REST z kolei uzyskują dostęp do mojej wspólnej warstwy usług.

Chcę, aby autoryzacja odbywała się w tej wspólnej warstwie usług, a nie w kontrolerach ASP.Net MVC lub w mojej odsłoniętej warstwie usługi REST.

Czy mogę utworzyć atrybut ASP.Net MVC Authorize podobny do dekoracji moich metod w wspólnej bibliotece klasy C#? Ten atrybut pobierze parametry i zdecyduje, czy bieżący użytkownik ma dostęp do tej funkcji, czy nie?

Dzięki & Pozdrawiam, Ajay

Answer 1

To, czego szukasz, można uzyskać za pomocą biblioteki AOP, takiej jak PostSharp (http://www.postsharp.org/). Jest bardziej skomplikowany niż użycie atrybutu Authorize w mvc, ale nadal jest dość prosty.

Answer 2

Nie, AuthorizeAttribute działa, ponieważ ramy MVC wyraźnie powołuje go przed wywołaniem metody. Podobna funkcja dla warstwy usługi działałaby tylko wtedy, gdyby klienci również ją jawnie wywołali. Nie byłoby rozsądnym założenie, że nawet klient o dobrych intencjach zawsze będzie pamiętać, aby wyszukać atrybut i go przywołać. WCF has its own security. Powinieneś użyć tego zamiast pisać własne.

Answer 3

To nie powinno być zbyt trudne do zrobienia - istnieje kilka miejsc, które można zastanowić się atrybut i obsługiwać go odpowiednio:

• Na starcie programu w Global.asx można dostosować routing i lokalizacje dla poglądów

• Bazowe ASP.Net zdarzenia żądania nadal ognia, więc można zastąpić jednego z nich

• Stwórz własną podstawowy kontroler i zastąpić OnActionExecuting

---

Aktualizacja następujący komentarz

Ach, widzę. W takim przypadku, jeśli wykonujesz połączenia bezpośrednie, powinieneś sprawdzić numer Code Access Security, który moim zdaniem obejmuje to, co masz na myśli.

Alternatywnie, atrybut niestandardowy może mieć sens, o ile używasz jakiegoś wzoru fabrycznego - wtedy wywołanie odbicia, które dostaje fabryka, może sprawdzić atrybuty.

Jeśli nie używasz refleksji do pobierania klas lub wywoływania metod (co w istocie ma miejsce w przypadku routingu w MVC), wtedy nie będziesz mieć szansy na sprawdzenie swoich atrybutów.

Answer 4

Innym sposobem radzenia sobie z tym problemem jest użycie atrybutu [PrincipalPermission] w warstwie usług. Może to uniemożliwić wywołującym wykonanie metody (lub uzyskanie dostępu do całej klasy) bez zdefiniowanej autoryzacji.