Dzisiaj dosyć ważne zagadnienie, a mianowicie filtry autoryzacji. Stosuje się je po to, aby wymusić autoryzację danej akcji i w razie braku autoryzacji po prostu ją zablokować. To co wyróżnia w/w filtry to najwyższy priorytet uruchamiania, co oznacza, że zostaną uruchomione na samym początku, przed jakimikolwiek filtrami oraz akcjami. Nasz kochany .NET udostępnia atrybut AuthorizeAttribute (implemetujący IAuthorizationFilter, z którego można korzystać przy autoryzacji, ale czym byłby świat programowania bez własnych implementacji 🙂
Przykładowa implementacja (bardzo, ale to bardzo prosta):
public class BakersAuthorizeAttribute : AuthorizeAttribute // dziedziczymy po wbudowanym AuthorizeAttribute { private readonly string userRole; public BakersAuthorizeAttribute(string userRole) { this.userRole = userRole; } protected override bool AuthorizeCore(HttpContextBase httpContext) // metoda, przy pomocy której udzielamy dostępu do akcji bądź nie { if (httpContext.User.IsInRole(userRole)) // sprawdzamy, czy aktualny user jest piekarzem { return true; // jeśli tak - uzyskuje on dostęp do akcji BakeBread } return false; // jeśli nie, błąd 401 - nieuprawnionym wstęp wzbroniony } }
Natomiast samo użycie filtra:
[BakersAuthorize("Piekarz")] public ActionResult BakeBread() { ViewBag.Message = "Your application description page."; return View(); }
Jeśli chodzi o sam AuthorizeAttribute, należy pamiętać o tym, że umożliwia autoryzację, ale nie zajmuje się uwierzytelnianiem!!!
Przepraszam, że się czepiam, ale nie istnieje takie słowo jak autentykacja 🙂 Authentication to naszemu uwierzytelnianie!
a jaki jest sens pisania własnej implementacji ?
skoro mogę napisać to tak :
[Authorize(Role=”Piekarz”)]
public ActionResult BakeBread()
{
ViewBag.Message = „Your application description page.”;
return View();
}
W tym wpisie nie chodzi o to czy jest sens, czy tego sensu nie ma, tylko o pokazanie jak to wygląda od strony WŁASNEJ, prawidłowej implementacji, którą potem można w dowolną stronę rozszerzać.
Sens pisania własnej implementacja pojawia się np. wtedy, gdy biznes wymaga nieszablonowych metod kontroli dostępu do zasobów i same role są niewystarczające. Przykład: Oprócz ról mamy uprawnienia efektywne per funkcjonalność. Użytkownik może mieć uprawnienie efektywne przypisane wprost lub może ono wynikać z grupy, do której należy.
[Authorize(Role=”Piekarz”)] wybacz ale to jest naprawde mierne rozwiazanie – standardowej implementacji w wiekszosci aplikacji (tych troche bardzie zlozonych) nie da sie po prostu uzywac.
Dzięki – to tak jak z notyfikacją/powiadomieniem – niby wiemy, ale jednak 🙂
Fakt, faktem, że Maciek mógł lepiej dobrać przykład 😉