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 thoughts on “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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s