ASP.NET MVC – własne filtry autoryzacji

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!!!

7 uwag do wpisu “ASP.NET MVC – własne filtry autoryzacji

    1. 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();
      }

      1. 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ć.

      2. 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.

      3. [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.

Zostaw komentarz

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

w

Connecting to %s