Category Archives: ASP.NET MVC

Jak dodać kontener Autofac do aplikacji ASP.NET MVC?

IoC piękna rzecz, spójrzmy jak dodać kontener IoC Autofac do aplikacji ASP.NET MVC.

W tym celu pobieramy NuGetem paczki Autofac i Autofac.Mvc5. Ponieważ jest to projekt MVC5, konieczna jest instalacja Autofac.Mvc5, dzięki temu będziemy mogli ustawić DependencyResolver na ten z Autofaca.

autofacMvc

Następnie musimy skonfigorować nasz kontener. Przechodzimy do klasy Global.asax.cs gdzie dodajemy metodę ConfigureContainer.

private void ConfigureContainer()
       {
           var builder = new ContainerBuilder();
           builder.RegisterControllers(typeof(MvcApplication).Assembly);
           builder.RegisterAssemblyModules(typeof(MvcApplication).Assembly);
           var container = builder.Build();
           DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
       }

private void ConfigureContainer()

{

var builder = new ContainerBuilder();

builder.RegisterControllers(typeof(MvcApplication).Assembly);

builder.RegisterAssemblyModules(typeof(MvcApplication).Assembly);

var container = builder.Build();

DependencyResolver.SetResolver(new AutofacDependencyResolver(container));

}

A jej wywołanie dodajemy do metody Application_Start()

protected void Application_Start()
      {
          ConfigureContainer();
          AreaRegistration.RegisterAllAreas();
          FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
          RouteConfig.RegisterRoutes(RouteTable.Routes);
          BundleConfig.RegisterBundles(BundleTable.Bundles);
      }

protected void Application_Start()

{

ConfigureContainer();

AreaRegistration.RegisterAllAreas();

FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);

RouteConfig.RegisterRoutes(RouteTable.Routes);

BundleConfig.RegisterBundles(BundleTable.Bundles);

}

W metodzie ConfigureContainer rejestrujemy kontrolery oraz moduły z bieżącego projektu.

Kontrolery mamy, ale nie mamy modułów. W modułach chcielibyśmy zarejestrować wszystkie typy z danego projektu. Dla przykładu załóżmy, że mamy projekt MVC i dwa pozostałe projekty, z czego jeden z nich zawiera serwisy, a drugi repozytoria. Stworzymy więc dwa moduły. Dodamy je do projektu MVC.

Każdy moduł musi dziedziczyć z klasy Module z biblioteki Autofac. W klasie modułu przeciążamy metodę Load, aby zarejestrować odpowiednie typy.

Moduł pierwszy dotyczy serwisów, chcemy zarejestrować w nim wszystkie typy z assembly Services.

public class ServiceModule : Module
    {
        protected override void Load(ContainerBuilder builder)
        {
            builder.RegisterAssemblyTypes(typeof(IDetermineServicesAssembly).Assembly).AsImplementedInterfaces().InstancePerRequest();
            base.Load(builder);
        }
    }

public class ServiceModule : Module

{

protected override void Load(ContainerBuilder builder)

{

builder.RegisterAssemblyTypes(typeof(IDetermineServicesAssembly).Assembly).AsImplementedInterfaces().InstancePerRequest();

base.Load(builder);

}

Dodajemy pusty interfejs IDetermineServicesAssembly do projektu z serwisami, służy on tylko po to aby określić z którego assembly rejestrować typy.

Kolejny moduł dotyczy repozytoriów. Analogicznie tworzymy nową klasę.

Przykład poniżej różni się od metody Load w module serwisów, ponieważ dodatkowo zarejestrowany jest typ UnitOfWork z inicjalizacją jego właściwości. Jest to przykład na to, że nic nie stoi na przeszkodzie zdefiniowania własnych customowych rejestracji.

public class RepoModule : Module
  {
      protected override void Load(ContainerBuilder builder)
      {
          base.Load(builder);
          builder.RegisterAssemblyTypes(typeof(IDetermineRepoAssembly).Assembly).AsImplementedInterfaces().InstancePerRequest();
          builder.RegisterType<UnitOfWork>().As<IUnitOfWork>().OnActivated(c =>
          {
              c.Instance.EventRepo = c.Context.Resolve<IEventRepo>();
              c.Instance.EventTypeRepo = c.Context.Resolve<IEventTypeRepo>();
              c.Instance.LocationRepo = c.Context.Resolve<ILocationRepo>();
              c.Instance.UserRepo = c.Context.Resolve<IUserRepo>();
          }
          );
      }
  }

public class RepoModule : Module

{

protected override void Load(ContainerBuilder builder)

{

base.Load(builder);

builder.RegisterAssemblyTypes(typeof(IDetermineRepoAssembly).Assembly).AsImplementedInterfaces().InstancePerRequest();

builder.RegisterType<UnitOfWork>().As<IUnitOfWork>().OnActivated(c =>

{

c.Instance.EventRepo = c.Context.Resolve<IEventRepo>();

c.Instance.EventTypeRepo = c.Context.Resolve<IEventTypeRepo>();

c.Instance.LocationRepo = c.Context.Resolve<ILocationRepo>();

c.Instance.UserRepo = c.Context.Resolve<IUserRepo>();

}

);

}

Dodajemy pusty interfejs IDetermineRepoAssembly do projektu z repozytoriami i to wszystko. Uruchamiamy aplikacje i wszystko automagicznie działa 🙂 Autofac znajdzie wszystkie typy z danego assembly i odpowiadające im interfejsy (ponieważ zdefiniowaliśmy to w rejestracji typów).

Deploy web aplikacji do chmury

Jeżeli przy tworzeniu nowego projektu w Visual Studio nie zaznaczyliśmy opcji „Host in the cloud”, ale chcemy opublikować naszą aplikacje w chmurze Azure, to ten krótki poradnik może okazać się przydatny. Pierwszą rzeczą jaką musimy zrobić jest stworzenie web aplikacji w Azure.
Wybieramy Usługi aplikacji z portalu i klikamy dodaj

Po stworzeniu aplikacji, możemy pobrać profil jej ustawień klikając „Pobierz profil…”

Otwieramy solucję w Visual Studio, wybieramy projekt do deployu i wybieramy Publish, a następnie Import i wybieramy plik z profilem *.PublishSettings pobrany z portalu Azure.

Dla pewności możemy wykonać test połączenia oraz upragniony Publish. That’s it. Nasza aplikacja już działa na Azure, przynajmniej powinna, o ile stworzyliśmy wcześniej także bazę danych i zmieniliśmy odpowiednio ConnectionStringa w web.configu.

Logowanie za pomocą konta google

userLogin

W aplikacji ASP.NET MVC mamy możliwość rejestracji kont użytkowników, jednak co w przypadku gdy chcielibyśmy dać użytkownikom możliwość logowania kontami zewnętrznymi, takimi jak google, facebook, itp? Aby umożliwić logowanie kontami zewnętrznymi, musimy przede wszystkim zajrzeć do pliku Startup.Auth.cs i w metodzie ConfigureAuth odkomentować odpowiednie linie kodu.

// Uncomment the following lines to enable logging in with third party login providers
//app.UseMicrosoftAccountAuthentication(
// clientId: "",
// clientSecret: "");

//app.UseTwitterAuthentication(
// consumerKey: "",
// consumerSecret: "");

//app.UseFacebookAuthentication(
// appId: "",
// appSecret: "");

//app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
//{
// ClientId = "",
// ClientSecret = ""
//});

// Uncomment the following lines to enable logging in with third party login providers

//app.UseMicrosoftAccountAuthentication(

// clientId: "",

// clientSecret: "");

//app.UseTwitterAuthentication(

// consumerKey: "",

// consumerSecret: "");

//app.UseFacebookAuthentication(

// appId: "",

// appSecret: "");

//app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()

//{

// ClientId = "",

// ClientSecret = ""

//});

Jak widać możemy użyć kont Microsoft, Twitter, Facebook oraz Google. W tym poście skupimy się na logowaniu za pomocą konta Google. Tak więc musimy odkomentować ostatnią opcję:

app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
{
ClientId = "",
ClientSecret = ""
});

app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()

{

ClientId = "",

ClientSecret = ""

});

Niezbędne będzie podanie ClientId i ClientSecret, aby je uzyskać udajemy się pod adres: https://console.developers.google.com i tworzymy nowy projekt. Następnie przechodzimy do zakładki Credentials i wybieramy Create creadentials określając nazwę naszej aplikacji, rodzaj, itd. Należy wpisać także odpowiednie redirect Url. Authorized JavaScript origins: http://localhost:portNumber oraz Authorized redirect URls: http://localhost:portNumber/signin-google . Zamiast localhost:portNumber podajemy adres naszej aplikacji. Jeżeli uruchamiamy ją na localhoście to adres powinien tak właśnie wyglądać, tylko trzeba wpisać odpowiedni port z jakiego korzysta aplikacja. Oprócz tego musimy jeszcze aktywować Google+ API, w tym celu przechodzimy do naszego projektu i z głównego ekranu wszystkich dostępnych API wybieramy Google+ API i klikamy enable. Po przeklikaniu się przez kilka kroków dostaniemy wygenerowane klucze ClientId i ClientSecret, które należy skopiować do powyższej metody. Po uruchomieniu aplikacji naszym oczom ukaże się dodatkowa opcja logowania.

I w ten oto sposób użytkownicy będą mogli logować się do naszej aplikacji kontami google.

Atrybuty walidacji w modelu

Projektując formularze, chcielibyśmy aby użytkownik podał w polach odpowiednie dane. Co zrobić aby sprawdzić poprawność wpisywanych danych? Z pomocą przychodzą nam atrybuty walidacji, które udekorują właściwości naszego modelu. Pisząc o walidacji, trzeba wspomnieć że możliwości są dwie: walidacja po stronie klienta oraz walidacja po stronie serwera. Dobrze jest skorzystać z obu opcji i walidować dane już po stronie klienta, aby nie przesyłać żądań do serwera dla każdego pola. Aby aktywować walidację po stronie klienta w aplikacji ASP.NET MVC należy upewnić się czy w pliku web.config, w sekcji appSettings widnieje taki oto wpis:

<add key="ClientValidationEnabled" value="true" />

1	<add key="ClientValidationEnabled" value="true" />

Dzięki temu oraz atrybutom w modelu uzyskamy walidację w obu przypadkach. Jakie atrybuty mamy do dyspozycji? Poniżej przedstawiam listę, mam nadzieję że żadnego nie pominąłem 😉

[Required(ErrorMessage = „This field is required”)]

[EmailAddress(ErrorMessage=”Incorrect e-mail address”)]

[Range(1, 99, ErrorMessage = „Incorrect value, please type value 1-99″)]

[RegularExpression(@”^[A-Z]+[a-zA-Z’’-‘\s]*$”)]

[Compare(„NewValue”, ErrorMessage = „Values are not the same”)]

[DataType(DataType.Time)]

[StringLength(256, MinimumLength=3)]

[MaxLength(500)]

Przykład:
Mamy w modelu właściwość:

[Range(1, 999, ErrorMessage = "Incorrect value, please type value 1-999")]
public int? NumberOfAttendees { get; set; }

1 2	[Range(1, 999, ErrorMessage = "Incorrect value, please type value 1-999")] public int? NumberOfAttendees { get; set; }

Spróbujmy teraz wpisać w to pole wartość z poza podanego zakresu

Jak widać walidacja zadziałała, bez wysyłania żądania do serwera. W przypadku wyłączonego wykonywania JavaScript w przeglądarce użytkownika, walidacja po stronie klienta nie zadziała, ale walidacja po stronie serwera się wykona.

ViewBag, ViewData, TempData

Gdy już jesteśmy w temacie kontrolerów, warto także poruszyć temat przekazywania danych do widoków. Oczywiście robimy to za pomocą ViewModeli, ale istnieją także inne metody przekazywana danych. Do dyspozycji mamy takie obiekty jak:

ViewBag,
ViewData,
TempData.

ViewBag i ViewData są obiektami tworzonymi tylko na czas bieżącego żądania. Podczas przekierowania pod inny adres wartości w nich zawarte przyjmują wartość null. ViewData jest to słownik, którego kluczem jest string, a wartością typ object. Podczas używania wymagane jest sprawdzanie przed nullem i rzutowanie, aby uniknąć pojawienia się błędu.
ViewBag jest typu dynamic, więc może przyjąć dowolny typ. Nie wymaga rzutowania typów.
Nieco więcej różnic zawiera TempData. Pozawala on na przekazywanie danych pomiędzy dwoma żądaniami HTTP (bieżącym i kolejnym), przechowuje on dane przez cały czas trwania żądania HTTP. Pomaga utrzymać dane podczas przemieszczania się pomiędzy kontrolerami lub akcjami. Korzystając z TempData musimy zapewnić sprawdzenie wartości przed nullem oraz rzutowanie na odpowiedni typ, w celu uniknięcia wystąpienia błędu. Obiekt ten jest używany głównie do przechowywania jednorazowych wiadomości jak np. komunikaty błędów.
Przykład: chcemy przekazać wartości lokalizacji i typów do kontrolki DropDown w widoku.
Kod zawarty w kontrolerze:

// GET: Events/Create
[Authorize]
public ActionResult Create()
{
//ViewBag
ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

////ViewData
//ViewData["LocationId"] = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
//ViewData["TypeId"] = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
return View("Create");
}

// GET: Events/Create

[Authorize]

public ActionResult Create()

{

//ViewBag

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

////ViewData

//ViewData["LocationId"] = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

//ViewData["TypeId"] = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

return View("Create");

}

W obu przypadkach z ViewBag i ViewData wartości zostaną poprawnie przekazane do widoku.
Kod zawarty w widoku:

   <div class="form-group">
            @Html.LabelFor(model => model.LocationId, "LocationId", htmlAttributes: new { @class = "control-label col-md-2" })
            <div class="col-md-10">
                @Html.DropDownList("LocationId", null, htmlAttributes: new { @class = "form-control" })
                @Html.ValidationMessageFor(model => model.LocationId, "", new { @class = "text-danger" })
            </div>
        </div>

        <div class="form-group">
            @Html.LabelFor(model => model.TypeId, "TypeId", htmlAttributes: new {@class = "control-label col-md-2"})
            <div class="col-md-10">
                @Html.DropDownList("TypeId", null, htmlAttributes: new {@class = "form-control"})
                @Html.ValidationMessageFor(model => model.TypeId, "", new {@class = "text-danger"})
            </div>
        </div>

@Html.LabelFor(model => model.LocationId, "LocationId", htmlAttributes: new { @class = "control-label col-md-2" })

@Html.DropDownList("LocationId", null, htmlAttributes: new { @class = "form-control" })

@Html.ValidationMessageFor(model => model.LocationId, "", new { @class = "text-danger" })

</div>

@Html.LabelFor(model => model.TypeId, "TypeId", htmlAttributes: new {@class = "control-label col-md-2"})

@Html.DropDownList("TypeId", null, htmlAttributes: new {@class = "form-control"})

@Html.ValidationMessageFor(model => model.TypeId, "", new {@class = "text-danger"})

</div>

Możemy też bezpośrednio dobrać się do wartości zawartych w obiektach ViewBag i ViewData:

@ViewBag.LocationId;
@ViewBag.TypeId;

@ViewData["LocationId"];
@ViewData["TypeId"];

@ViewBag.LocationId;

@ViewBag.TypeId;

@ViewData["LocationId"];

@ViewData["TypeId"];

W przypadku TempData wygląda to tak samo.
Kod w kontrolerze:

// GET: Events/Create
[Authorize]
public ActionResult Create()
{
TempData["TestVal"] = "TempDataTestVal";
return View("Create");
}

// GET: Events/Create

[Authorize]

public ActionResult Create()

{

TempData["TestVal"] = "TempDataTestVal";

return View("Create");

}

Kod w widoku:

TempData: @TempData["TestVal"];

1	TempData: @TempData["TestVal"];

W przypadku przekazywania wartości TempData pomiędzy akcjami wygląda to tak:

// GET: Events
[Route("{Events}")]
public ActionResult Index()
{
TempData["TestVal"] = "TempDataTestVal";
return RedirectToAction("Create");
}

// GET: Events/Create
[Authorize]
public ActionResult Create()
{
var tesVal = TempData["TestVal"];
return View("Create");
}

// GET: Events

[Route("{Events}")]

public ActionResult Index()

{

TempData["TestVal"] = "TempDataTestVal";

return RedirectToAction("Create");

}

// GET: Events/Create

[Authorize]

public ActionResult Create()

{

var tesVal = TempData["TestVal"];

return View("Create");

}

Zapisujemy wartość do obiektu TempData w akcji index i przekierowujemy do akcji Create.
W akcji create pobieramy wartość TempData[„TestVal”] i sprawdzamy czy jest to „TempDataTestVal”.

Jak widać wartość została przekazana.

Routing w ASP.NET MVC

Routing jest to pewnego rodzaju wzór adresu URL, który mapowany jest do odpowiedniej akcji kontrolera lub po prostu do pliku który ma zostać zwrócony. Konfiguracja routingu znajduje się w klasie RouteConfig (w folderze App_Start), w statycznej metodzie RegisterRoutes. Metoda ta wywoływana jest w metodzie Aplication_Start() w klasie MvcApplication z pliku Global.asax.cs. Domyślnie w nowo stworzonym projekcie ASP.NET MVC klasa RouteConfig wygląda tak:

  public class RouteConfig
    {
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
            );
        }
    }

public class RouteConfig

{

public static void RegisterRoutes(RouteCollection routes)

{

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(

name: "Default",

url: "{controller}/{action}/{id}",

defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }

);

}

W ciele metody RegisterRoutes widzimy wywołanie metody IngoreRoute. Dzięki temu do listy ignorowanych ścieżek zostanie dodana ścieżka wskazująca na jakikolwiek zasób z rozszerzeniem .xsd. Metoda MapRoute, definiuje nam regułę routingu. Należy pamiętać o kolejności definiowanych zasad routingu, ponieważ działa tutaj reguła pierwszego dopasowania, pierwsza pasująca reguła zostanie użyta.
W ASP.NET MVC 5 dodatkowo wprowadzone zostały atrybuty routingu. W celu uruchomienia routingu na podstawie atrybutów należy dodać wywołanie Metody MapMvcAttribytesRoutes w metodzie RegisterRoutes:

routes.MapMvcAttributeRoutes();

1	routes.MapMvcAttributeRoutes();

Atrybuty routingu pozwalają na dekorowanie akcji atrybutem Route z określeniem zasady routingu:

     [Route("{Events}")]
        public ActionResult Index()
        {
            var events = _eventRepository.GetEvents();
            return View(events);
        }

        [Route("{Events}/{id}")]
        // GET: Events/Details/5
        public ActionResult Details(string id)
        {
            if (id == null)
            {
                return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
            }
            Event @event = _eventRepository.GetEventById(id);
            if (@event == null)
            {
                return HttpNotFound();
            }
            return View(@event);
        }

[Route("{Events}")]

public ActionResult Index()

{

var events = _eventRepository.GetEvents();

return View(events);

}

[Route("{Events}/{id}")]

// GET: Events/Details/5

public ActionResult Details(string id)

{

if (id == null)

{

return new HttpStatusCodeResult(HttpStatusCode.BadRequest);

}

Event @event = _eventRepository.GetEventById(id);

if (@event == null)

{

return HttpNotFound();

}

return View(@event);

}

Dodatkowo atrybuty mogą zawierać ograniczenia, np. :

[Route("{Events}/{id:X}")]

1	[Route("{Events}/{id:X}")]

Gdzie X jest ograniczeniem: datetime, decimal, double, float, guid, int, length(n), long, max(n), maxlength(n), min(n), minlength(n), range(n,m), regex(someRegExp).

Pisząc o routingu, należy także wspomnieć o możliwości definiowania obszarów. Kiedy chcemy użyć w naszej aplikacji kilku kontrolerów o takiej samej nazwie (np. jeden do panelu admina, a drugi dla pozostałych użytkowników), przydatne mogą się okazać obszary – RouteArea. Definiując obszar, wyeliminujemy problem wyboru odpowiedniego kontrolera.

[RouteArea("Area1")]
public class EventsController : Controller
{

...

}

[RouteArea("Area1")]

public class EventsController : Controller

{

...

}

Wtedy link do akcji kontrolera z uwzględnieniem obszaru prezentuje się następująco:

Url.Action("Index", "Events", new { Area = "Area1" })

1	Url.Action("Index", "Events", new { Area = "Area1" })

Kontroler i filtry akcji

spa-filters W poprzednim wpisie przyjrzeliśmy się kontrolerom oraz ich akcjom, natomiast teraz rzucimy okiem na filtry, czyli atrybuty, które można zastosować zarówno dla każdej z akcji jak i dla całego kontrolera. Atrybuty definiują nam sposób wykonania określonych akcji. W ASP.NET MVC mamy do dyspozycji kilka typów filtrów akcji:

Filtry autoryzacji – są wywoływane na samym początku, przed pozostałymi filtrami i akcją.
Decydują o możliwości wykonania metody po wcześniejszej autentykacji lub walidacji właściwości danego żądania. Implementują interfejs IAutorizationFilter zawierający metodę OnAuthorization.
Filtry akcji – zapewniają wykonanie dodatkowych operacji, zarówno przed jak i po wykonaniu akcji. Implementują interfejs IActionFilter, który zawiera dwie metody: OnActionExecuting i OnActionExecuted. Pierwsza z nich wykonuje się przed daną akcją, natomiast druga wykonuje się po zakończeniu akcji.
Filtry rezultatu – opakowują wywołanie obiektu typu ActionResult. Implementują interfejs IResultFilter, który zawiera dwie metody podobnie jak interfejs dla filtrów akcji. Jedna z nich to OnResultExecuting i wykonuje się przed zwróceniem rezultatu, a druga to OnResultExecuted i wykonuje się po zwróceniu rezultatu.
Filtry wyjątków – wykonują się gdy nastąpi nieobsłużony wyjątek gdzieś w akcji. Implementują interfejs IExceptionFilter zawierający metodę OnException.

Teraz zobaczmy jak można z tych filtrów skorzystać. Użyjemy najpierw filtra autoryzacji. Chcemy wykonać akcję tylko w momencie gdy użytkownik będzie zautoryzowany. W tym celu dekorujemy naszą metodę atrybutem [Authorize] i to wszystko.

[Authorize]
public ActionResult Delete(string id)
{
  …
}

[Authorize]

public ActionResult Delete(string id)

{

…

}

Kolejnym zaimplementowanym filtrem, którego możemy użyć jest [HandleError], który określa sposób łapania wyjątków.

[HandleError]
public ActionResult Delete(string id)
{
  …
}

[HandleError]

public ActionResult Delete(string id)

{

…

}

W przypadku gdy zechcemy wymusić korzystanie z połączenia po HTTPS wystarczy użyć atrybutu [RequireHttps]

[RequireHttps]
public ActionResult Delete(string id)
{
  …
}

[RequireHttps]

public ActionResult Delete(string id)

{

…

}

Kolejny ważniejszy atrybut to [ValidateAntiForgeryToken], o nim była mowa w jednym z poprzednich postów o CSRF. Za jego pomocą sprawdzane są klucze (ten wygenerowany w formularzu z kluczem przesłanym w żądaniu).

[HttpPost]
[Authorize]
[ValidateAntiForgeryToken]
public ActionResult Edit(Event @event)
{
if (ModelState.IsValid)
{
  …
}
return View(@event);
}

[HttpPost]

[Authorize]

[ValidateAntiForgeryToken]

public ActionResult Edit(Event @event)

{

if (ModelState.IsValid)

{

…

}

return View(@event);

}

Nic nie stoi na przeszkodzie, aby dodawać kilka filtrów do jednej akcji. Możemy również tworzyć własne filtry, implementując odpowiednie interfejsy.
Wspomniałem na początku, że filtry można zastosować nie tylko do konkretnych metod kontrolera, ale też do całej klasy. Można to zrobić np. w ten sposób:

[Authorize]
public class EventsController : Controller
{
…

[Authorize]

public class EventsController : Controller

{

…

Dzięki temu, każda akcja wymaga autoryzacji do wykonania, bez konieczności powielania atrybutu dla każdej akcji.

Oprócz wyżej wymienionych, mamy do dyspozycji jeszcze kilka innych ciekawych atrybutów takich jak:

ValidateInput – walidacja danych wejściowych
HttpGet – obsługa żądania GET, nie trzeba dodawać tego atrybutu, ponieważ domyślnie metoda obsługuje żądania GET
HttpPost – obsługa żądania POST
OutputCache – powoduje cachowanie metody, możliwe jest określenie czasu przechowywania w cachu

Kontroler i Akcje

W tym wpisie przyjrzymy się kontrolerom w aplikacji ASP.NET MVC oraz akcjom, które mogą one zawierać. Kontrolery są odpowiedzialne za odpowiadanie na żądania użytkownika. Każde żądanie kierowane z przeglądarki jest obsługiwane przez określony kontroler. Przykładowo użytkownik klika przycisk odpowiadający za dodanie nowego wydarzenia, natomiast kontroler (EventsController) w odpowiedzi wyświetla odpowiedni widok. Akcja, która się w tym przypadku wykona jest zawarta w metodzie Create typu GET.

// GET: Events/Create
[Authorize]
public ActionResult Create()
{
ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
return View();
}

// GET: Events/Create

[Authorize]

public ActionResult Create()

{

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

return View();

}

Zgodnie z dobrymi praktykami należy pamiętać, że w kontrolerze nie powinno być zawartej logiki biznesowej, ani logiki odpowiedzialnej za dostęp do danych. No dobrze, ale jak to się dzieje że akcje są wykonywane przez odpowiednie metody kontrolera? Za to odpowiedzialny jest routing. Przykładowo wywołujemy URL: http://localhost/Events/Create i w tym przypadku zostanie wywołana metoda Create() z klasy EventsController. Akcje kontrolera muszą być metodami publicznymi. Także każda metoda publiczna w kontrolerze staje się wystawioną na zewnątrz akcją. Każda akcja zwraca typ ActionResult. W przypadku powyższej metody Create zwracany jest typ ViewResult. Wystarczy zwrócić wynik metody View(), a zwrócony zostanie widok o nazwie Create znajdujący się w katalogu Events (czyli o takiej samej nazwie jak kontroler). Identyczny efekt osiągniemy gdy wywołamy metodę View(„Create”), wtedy jawnie wskazujemy nazwę widoku. Poza typem ViewResult w ASP.NET MVC jest dostępnych jeszcze kilka innych typów. Lista wszystkich typów prezentuje się następująco:

ViewResult – zwraca widok
PartialViewResult – zwraca widok częściowy
EmptyResult – zwraca null
RedirectResult – przekierowuje do innej akcji za pomocą adresu URL
RedirectToRouteResult – przekierowuje do innej akcji bez odwiedzania adresu URL
JsonResult – zwraca dane w postaci JSON
JavaScriptResult – zwraca kod w postaci JavaScript
ContentResult – zwraca wartość tekstową
FileContentResult – reprezentuje plik do pobrania, jako tablicę bitów
FilePathResult – zwraca ścieżkę do pliku
FileStreamResult – reprezentuje plik do pobrania, jako strumień danych

Każdy z typów dziedziczy z klasy bazowej ActionResult. Poniżej znajdują się przykładowe implementacje akcji:

        public ActionResult Partial()
        {
            var events = _eventRepository.GetEvents();
            return PartialView("Index", events);
        }

        public ActionResult EmptyResult()
        {
            return new EmptyResult();
        }

        public ActionResult RedirectResult()
        {
            var locations = _locationRepository.GetLocations();
            return RedirectToAction("Index", locations);
        }

        public ActionResult RedirectToRouteResult()
        {
            return RedirectToRoute("Index", "Home");
        }

        public ActionResult JsonResult()
        {
            return Json(new { Id = 2016, Name="BreakingChanges" });
        }

        public ActionResult JavaScriptResult()
        {
            return JavaScript("alert('Hello World')");
        }

        public ActionResult ContentResult()
        {
            return Content("TestContent");
        }

        public ActionResult FileContentResult()
        {
            string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");
            return File(System.IO.File.ReadAllBytes(path), "application/x-msdownload");
        }

        public ActionResult FilePathResult()
        {
            string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");
            return File(path, "application/x-msdownload", "virus.exe");
        }

        public ActionResult FileStreamResult()
        {
            string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");
            return File(System.IO.File.OpenRead(path), "application/x-msdownload");
        }

public ActionResult Partial()

{

var events = _eventRepository.GetEvents();

return PartialView("Index", events);

}

public ActionResult EmptyResult()

{

return new EmptyResult();

}

public ActionResult RedirectResult()

{

var locations = _locationRepository.GetLocations();

return RedirectToAction("Index", locations);

}

public ActionResult RedirectToRouteResult()

{

return RedirectToRoute("Index", "Home");

}

public ActionResult JsonResult()

{

return Json(new { Id = 2016, Name="BreakingChanges" });

}

public ActionResult JavaScriptResult()

{

return JavaScript("alert('Hello World')");

}

public ActionResult ContentResult()

{

return Content("TestContent");

}

public ActionResult FileContentResult()

{

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");

return File(System.IO.File.ReadAllBytes(path), "application/x-msdownload");

}

public ActionResult FilePathResult()

{

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");

return File(path, "application/x-msdownload", "virus.exe");

}

public ActionResult FileStreamResult()

{

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");

return File(System.IO.File.OpenRead(path), "application/x-msdownload");

}

Zabezpieczenie przed atakami CSRF w ASP.NET MVC

CSRF czyli Cross-Site Request Forgery jest to w skrócie zmuszenie przeglądarki ofiary do wykonania nieautoryzowanej akcji (za pomocą żądania HTTP). Ofiarą jest zalogowany do serwisu użytkownik. Celem takiego ataku może być podmiana danych w formularzu lub też wykonanie innej akcji np. stworzenie konta użytkownika z uprawnieniami admina. Wypadałoby się przed tym zabezpieczyć tworząc aplikacje webową. Na szczęście mechanizm zabezpieczeń otrzymujemy w ASP.NET MVC out of the box 🙂
Pokażmy to na przykładzie. Mamy kontroler eventów, który zawiera metody Edit – Get i Post.

        // GET: Events/Edit/5
        [Authorize]
        public ActionResult Edit(string id)
        {
            if (id == null)
            {
                return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
            }
            Event @event = _eventRepository.GetEventById(id);
            if (@event == null)
            {
                return HttpNotFound();
            }
            ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
            ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
            return View(@event);
        }

        // POST: Events/Edit/5
        [HttpPost]
        [Authorize]
        public ActionResult Edit(Event @event)
        {
            if (ModelState.IsValid)
            {
                try
                {
                    _eventRepository.Update(@event);
                    _eventRepository.SaveChanges();
                }
                catch (Exception ex)
                {
                    ViewBag.Error = true;
                    return View(@event);
                }
            }
            ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
            ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
            ViewBag.Error = false;
            return View(@event);
        }

// GET: Events/Edit/5

[Authorize]

public ActionResult Edit(string id)

{

if (id == null)

{

return new HttpStatusCodeResult(HttpStatusCode.BadRequest);

}

Event @event = _eventRepository.GetEventById(id);

if (@event == null)

{

return HttpNotFound();

}

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

return View(@event);

}

// POST: Events/Edit/5

[HttpPost]

[Authorize]

public ActionResult Edit(Event @event)

{

if (ModelState.IsValid)

{

try

{

_eventRepository.Update(@event);

_eventRepository.SaveChanges();

}

catch (Exception ex)

{

ViewBag.Error = true;

return View(@event);

}

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

ViewBag.Error = false;

return View(@event);

}

Teraz wystarczy, że haker skłoni nas do wyświetlenia strony zawierającej formularz z auto submitem, przez niego spreparowany z wpisanymi wartościami, np. strona HTML może zawierać taki kawałek kodu:

<form id="eventForm" action="http://localhost:6875/Events/Edit/88611f5e-fb27-479d-8437-e8e1fe8dcd38" method="post">        
        <input id="Id" name="Id" type="hidden" value="88611f5e-fb27-479d-8437-e8e1fe8dcd38">
        <div class="form-group">
            <label class="control-label col-md-2" for="StartDate">Data rozpoczęcia</label>
            <div class="col-md-10">
                <input class="form-control datepicker text-box single-line" data-val="true" id="StartDate" name="StartDate" type="date" value="2022-04-06">
                <span class="field-validation-valid text-danger" data-valmsg-for="StartDate" data-valmsg-replace="true"></span>
            </div>
        </div>     
</form>
<script type="text/javascript">
    document.getElementById('eventForm').submit();
</script>

<label class="control-label col-md-2" for="StartDate">Data rozpoczęcia</label>

</div>

</form>

document.getElementById('eventForm').submit();

</script>

W przykładzie tym została podmieniona data rozpoczęcia eventu. Nie jest to co prawda jakaś bardzo inwazyjna operacja, ale obrazuje działanie CSRF. W przypadku braku zabezpieczeń, data wybranego wydarzenia zostanie zaktualizowana. Z pomocą przychodzi nam atrybut [ValidateAntiForgeryToken], którym możemy udekorować naszą metodę Edit.

        // POST: Events/Edit/5
        [HttpPost]
        [Authorize]
        [ValidateAntiForgeryToken]
        public ActionResult Edit([Bind(Include = "Id,CreationDate,Name,Description,StartDate,StartTime,EndDate,EndTime,LocationId,TypeId,Objective,NumberOfAttendees,UserId")] Event @event)
        {
            if (ModelState.IsValid)
            {
                try
                {
                    _eventRepository.Update(@event);
                    _eventRepository.SaveChanges();
                }
                catch (Exception ex)
                {
                    ViewBag.Error = true;
                    return View(@event);
                }
            }
            ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
            ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
            ViewBag.Error = false;
            return View(@event);
        }

// POST: Events/Edit/5

[HttpPost]

[Authorize]

[ValidateAntiForgeryToken]

public ActionResult Edit([Bind(Include = "Id,CreationDate,Name,Description,StartDate,StartTime,EndDate,EndTime,LocationId,TypeId,Objective,NumberOfAttendees,UserId")] Event @event)

{

if (ModelState.IsValid)

{

try

{

_eventRepository.Update(@event);

_eventRepository.SaveChanges();

}

catch (Exception ex)

{

ViewBag.Error = true;

return View(@event);

}

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

ViewBag.Error = false;

return View(@event);

}

Ponadto w widoku musi się znaleźć taki fragment kodu:

@using (Html.BeginForm())
{
@Html.AntiForgeryToken()
…
}

@using (Html.BeginForm())

{

@Html.AntiForgeryToken()

…

}

powoduje to wygenerowanie ciasteczka i klucza, który jest ukryty w formie i wygląda tak:

<input name="__RequestVerificationToken" type="hidden" value="p-mEYr9SQrDvvCGU-ness9maQwrd7iN1ei1FUd5ieKQpXjjGNQKMHyTqER9o9GDqOm4o5cqS27JRWwZBE-R2FUitBnnWI83tMTJ3lq4zrzawzDeAPFKx-3Kf3p5eI1ouRUhfsYWElXnPhGM0fRsWkw2">

1	<input name="__RequestVerificationToken" type="hidden" value="p-mEYr9SQrDvvCGU-ness9maQwrd7iN1ei1FUd5ieKQpXjjGNQKMHyTqER9o9GDqOm4o5cqS27JRWwZBE-R2FUitBnnWI83tMTJ3lq4zrzawzDeAPFKx-3Kf3p5eI1ouRUhfsYWElXnPhGM0fRsWkw2">

W żądaniu POST ciasteczko jest przesyłane i za pomocą atrybutu [ValidateAntiForgeryToken] sprawdzana jest zgodność klucza. Gdy klucz nie będzie zgodny, wystąpi błąd. Dodatkowo w metodzie Edit można dodać jeszcze jedno zabezpieczenie, chodzi o binding.

public ActionResult Edit([Bind(Include = "Id,CreationDate,Name,Description,StartDate,StartTime,EndDate,EndTime,LocationId,TypeId,Objective,NumberOfAttendees,UserId")] Event @event)

1	public ActionResult Edit([Bind(Include = "Id,CreationDate,Name,Description,StartDate,StartTime,EndDate,EndTime,LocationId,TypeId,Objective,NumberOfAttendees,UserId")] Event @event)

Dzięki temu określamy jakie dane mogą zostać zapisane, ponadto w żądaniu sprawdzane są typy i wartości. Poprawność danych wskaże nam właściwość ModelState.IsValid.

Podsumowując, nie należy ignorować podatności CSRF i odpowiednio się przed nią zabezpieczyć. Na szczęście ASP.NET MVC robi to za nas 🙂

DateTime w widoku edycji

Dzisiejszy wpis poświęcony będzie typowi DateTime. Wyświetlając widok edycji zdarzenia, natrafiłem na taki oto problem. Pomimo tego, że zdarzenie ma zapisaną datę, co potwierdza metoda Edit typu GET, więc data powinna zostać załadowane do widoku, tak się jednak nie dzieje.

W widoku zamiast daty rozpoczęcia, widzimy dd.mm.rrrr, dodatkowo możemy wybrać jakąś datę z date pickera (działa tylko w Chrome).

Ten sam przykład w przeglądarce Internet Explorer

W IE nie ma date pickera ponieważ IE nie wspiera typu date, ale data wyświetlana jest prawidłowo. No dobrze to przyjrzyjmy się w takim razie naszemu modelowi. Kod właściwości Data rozpoczęcia prezentuje się tak:

[Display(ResourceType = typeof(Resources.Event), Name = "StartDate")]
[Required]
[DataType(DataType.Date)]
[DisplayFormat(DataFormatString = "{0:dd-MM-yyyy}", ApplyFormatInEditMode = true)]
public DateTime StartDate { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "StartDate")]

[Required]

[DataType(DataType.Date)]

[DisplayFormat(DataFormatString = "{0:dd-MM-yyyy}", ApplyFormatInEditMode = true)]

public DateTime StartDate { get; set; }

Kluczowym elementem jest tutaj atrybut DisplayFormat. Aby rozwiązać problem wystarczy zmienić format wyświetlanej daty na yyyy-MM-dd, tylko w taki sposób przeglądarka sobie z tym poradzi. Poprawiony kod właściwości Data rozpoczęcia:

[Display(ResourceType = typeof(Resources.Event), Name = "StartDate")]
[Required]
[DataType(DataType.Date)]
[DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
public DateTime StartDate { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "StartDate")]

[Required]

[DataType(DataType.Date)]

[DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]

public DateTime StartDate { get; set; }

Taka sama sytuacja ma miejsce w przypadku time pickerów.

Kod w modelu dla właściwości Czas zakończenia wygląda następująco.

[Display(ResourceType = typeof(Resources.Event), Name = "EndTime")]
[Required]
[DataType(DataType.Time)]
[DisplayFormat(DataFormatString = "{0:hh-mm}}", ApplyFormatInEditMode = true)]
public DateTime EndTime { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "EndTime")]

[Required]

[DataType(DataType.Time)]

[DisplayFormat(DataFormatString = "{0:hh-mm}}", ApplyFormatInEditMode = true)]

public DateTime EndTime { get; set; }

Po zmianie formatu na hh:mm:ss, problem zostaje rozwiązany. Poniżej kod po poprawkach.

[Display(ResourceType = typeof(Resources.Event), Name = "EndTime")]
[Required]
[DataType(DataType.Time)]
[DisplayFormat(DataFormatString = "{0:hh:mm:ss}", ApplyFormatInEditMode = true)]
public DateTime EndTime { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "EndTime")]

[Required]

[DataType(DataType.Time)]

[DisplayFormat(DataFormatString = "{0:hh:mm:ss}", ApplyFormatInEditMode = true)]

public DateTime EndTime { get; set; }

Jak widać format ma znaczenie 😉

P	W	Ś	C	P	S	N
« Maj
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31

Jakub Skoczeń

.NET Developer

Category Archives: ASP.NET MVC

Jak dodać kontener Autofac do aplikacji ASP.NET MVC?

Deploy web aplikacji do chmury

Logowanie za pomocą konta google

Atrybuty walidacji w modelu

ViewBag, ViewData, TempData

Routing w ASP.NET MVC

Kontroler i filtry akcji

Kontroler i Akcje

Zabezpieczenie przed atakami CSRF w ASP.NET MVC

DateTime w widoku edycji