Filtry na swój sposób stanowią kolejny etap przetwarzania zapytania wysyłanego przez przeglądarkę klienta.
Możemy je podzielić na cztery podstawowe typy:
Authorization - uruchamiają się najwcześniej - określają prawa dostępu do danego kontrolera/akcji
Action - wywoływane przed i po akcji
Result - przed i po otrzymaniu rezultatu akcji
Exception - kiedy inny filtr, akcja lub rezultat akcji zwróci wyjątek
Własne filtry tworzymy poprzez:
- dziedziczenie po klasie FilterAttribute
- zaimplementowanie któregoś z czterech interfejsów
Filtry można przypisywać do całego kontrolera jak i pojedynczych akcji. W przypadku umieszczenia filtra tego samego typu na całym kontenerze oraz akcji, filtr umieszczony na akcji nadpisze filtr kontrolera. Oczywiście tyczy się to filtrów, które nie są oznaczone atrybutem AllowMultiple=true. Jeżeli tak by było, wówczas oba filtry zostaną uwzględnione.
Używanie filtrów autoryzacji:
Na akcję lub cały kontroler nakładamy atrybut:
[Authorize]
[Authorize(Users="Patryk, Krzysztof")]
[Authorize(Roles="Administrator")]
public class Default1Controller : Controller
{
//
// GET: /Default1/
public ActionResult Index()
{
return View();
}
}
Nie jest to trudne i raczej łatwo skojarzyć co dana właściwość znaczy. W przypadku filtru i na grupę i na użytkowników - oba warunki muszą zostać spełnione.
Tworzenie własnego filtru autoryzacji rozpoczynam od dziedziczenia po klasie AuthorizeAttribute i nadpisujemy wirtualną funkcję AuthorizeCore:
public class MyAuthorize : AuthorizeAttribute
{
public bool allowLocalResources = false;
protected override bool AuthorizeCore(HttpContextBase httpContext)
{
if (allowLocalResources && httpContext.Request.IsLocal)
{
return true;
}
return base.AuthorizeCore(httpContext);
}
}
Użycie tak stworzonego filtru:
[MyAuthorize(Roles="Admin", allowLocalResources="true")]
Używanie filtrów wyjątków
Filtry wyjątków przydatne są w sytuacjach:
- logowania wystąpienie wyjątku
- wyświetlenia odpowiedniego komunikatu użytkownikowi
Właściwości filtra HandleErrorAttribute:
- ExceptionType - domyślnie System.Exception
- View - nazwa widoku który zostanie wygenerowany dla użytkownika
- Master - MasterPage użyty przy renderowaniu widoku
Ważne: aby wyłapywanie wyjątków działało w webconfig dodajemy: Tworzenie własnego filtra wyjątku
Implementujemy interfejs IExceptionFilter oraz klasę FilterAttribute:
public class MyException : FilterAttribute, IExceptionFilter
{
public void OnException(ExceptionContext filterContext)
{
if (filterContext.ExceptionHandled)
{
return;
}
filterContext.Controller.TempData["exception"] = filterContext.Exception;
filterContext.Result = new RedirectToRouteResult(new RouteValueDictionary(new { controller = "Exception", action = "akcja" }));
filterContext.ExceptionHandled = true;
filterContext.HttpContext.Response.Clear();
}
}
Tak więc nic trudnego.
Casching filters
Dzięki nim można wykorzystać wynik zapytania bez potrzeby ponownego wywoływania akcji. Parametry:
Duration - czas przechowywania kopi danych
VaryByParam - parametry przekazane do żądania
Location - gdzie zostanie przechowany wynik działania mechanizmu
Parametr [ActionName("Prodkukty")] Pozwala nadać nazwę akcji. Może się to przydać wtedy kiedy musimy mieć dwie te same akcje (te same nazwy i argumenty). Co prawda nie da się stworzyć dwóch takich samych definicji metod, jednak za pomocą ActionName możemy za-symulować takie zjawisko.
Brak komentarzy:
Prześlij komentarz