Paweł Łukasiewicz
2019-03-03
Paweł Łukasiewicz
2019-03-03
Udostępnij Udostępnij Kontakt
Wprowadzenie

Platforma ASP.NET Core ciągle ewoluuje, wprowadzane są kolejne zmiany, modyfikacje i ulepszenia. Jeden z kolejnych artykułów będzie poświecony wersji ASP.NET Core 3.0. Jednakże z doświadczeniam wiem, że większość z nas zatrzymała się na wersji 2.0. Omówimy zatem pokrótce zmiany, które pojawiły się w wersji 2.1 zanim przejdziemy do kolejnej, która wprowadziła kilka istotnych i dużych zmian w stosunku do swoich poprzedników. Wersja 2.1 określona jest akronimem LTS (long term support) podczas gdy wsparcie dla wersji 2.0 zostało już zaniechane. Wszelkie dodatkowe informacje możecie znaleźć pod adresem https://dotnet.microsoft.com/download/archives

Aby używać ASP.NET Core 2.1 musimy dokonać instalacji wymaganych komponentów:

  • .NET Core 2.1 Preview 1 Runtime;
  • lub NET Core 2.1 Preview 1 SDK (paczka zawiera w sobie środowisko uruchomieniowe).
  • Visual Studio 15.7 - jeżeli chcesz sprawdzić z jakiej wersji obecnie korzystasz udaj się do głównego Menu, zakładki Help i elementu About Microsoft Visual Studio. W moim przypadku jest to wersja 15.8.8: Wersja Visual Studio Jeżeli Twoja wersja jest niższa skorzystaj z aktualizacji całego środowiska zanim przejdziesz do następnych kroków.

ASP.NET Core 2.1

Po poprawnym ukończeniu instalacji będziesz w stanie korzystać z szablonu ASP.NET Core w wersji 2.1: ASP.NET Core 2.1

Na powyższym zrzucie ekranu możecie zobaczyć 4 różne wersje. Wszystko dlatego, że kiedy pojawił się .NET Core starałem się być w miarę na bieżaco z każdą wersją, żeby śledzić zmiany zachodzące w projekcie. W tym artykule skupimy się na wersji 2.1 - utwórzcie projekt z szablonu Web Application (Model-View-Controller).

ASP.NET Core 2.1 wprowadza nowy meta-pakiet do wykorzystania przez aplikacje: Microsoft.AspNetCore.App. Każdy nowy projekt utworzony w ramach wersji 2.1 będzie korzystał z tego meta-pakietu. Definicję zależności możecie sprawdzić w poniższej sekcji: Microsoft.AspNetCore.App W poprzedniej wersji korzystaliśmy z paczki, która zawierała znacznie więcej zależności: Microsoft.AspNetCore.All

Główną różnicą pomiędzy paczką Microsoft.AspNetCore.All a Microsoft.AspNetCore.App jest zmniejszenie liczby zależnych pakietów nie będacych własnością bądź nie obsługiwanych przez zespoły programistów ASP.NET oraz .NET. Jeżeli chcesz dowiedzieć się więcej, poznać usnięte paczki udaj się na profil GitHub zespołu ASP.NET pod adresem https://github.com/aspnet/Announcements/issues/287

HTTPS

Zrób build i uruchom aplikację. Zostanie wyświetlone ostrzeżenie związane z certyfikatem SSL. Domyślnie, ASP.NET Core 2.1 będzie działał w oparciu o protokół HTTPS. Dojdzie do konfiguracji certyfikatu dla środowiska programistycznego: dotnet: instalacja certyfikatu Po udzieleniu akceptacji na instalację wyskoczy kolejne ostrzeżenie: dotnet: instalacja certyfikatu Od teraz jesteśmy w stanie uruchomić nasz projekt lokalnie w oparciu o HTTPS: Localhost Https Jest to niesamowite ułatwienie w stosunku do technologii .NET Framework.

Jeżeli jednak z jakichkolwiek przyczyn nie byliście w stanie wykonać powyższych kroków, tzn. nie doszło do instalacji ceryfikatu a Wy możecie zobaczyć, że Wasze połączenie nie jest bezpieczne: Localhost Https oznacza to, że niezaufany ceryfikat SSL został wygenerowany wcześniej: Localhost Http

Przy użyciu narzędzia wbudowanego w .NET Core 2.1, tzn. dotnet jesteśmy w stanie wymusić instalację za pomocą poniższej komendy:

dotnet dev-certs https --trust
Sam proces zajmuje trochę czasu dlatego warto być cierpliwym i poczekać, aż pojawi nam się Security Warning: dotnet: instalacja certyfikatu Po ukończeniu instalacji jesteśmy w stanie wyświetlić nasza strone poprawnie: Localhost Https

Warto również zajrzeć do pliku Startup.cs. Domyślne przekierowanie HTTPS jest zawarte w ASP.NET Core a na serwerze produkcyjnym będzie dodatkowo używane HSTS (HTTP Strict Transport Security) – jest to specjalna impelementacja bezpieczeństwa, która nigdy nie dopuszcza połączeń na bazie niebezpiecznego protokołu HTTP. Implementacja ta ma na celu m.in. zabezpieczenie przed przechwyceniem sesji.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
	if (env.IsDevelopment())
	{
		app.UseDeveloperExceptionPage();
	}
	else
	{
		app.UseExceptionHandler("/Home/Error");
		// Użycie mechanizmu zabezpieczenia sieci HSTS
		app.UseHsts();
	}
	// Domyślne przekierowanie do HTTPS
	app.UseHttpsRedirection();
	app.UseStaticFiles();
	app.UseCookiePolicy();
	app.UseMvc(routes =>
	{
		routes.MapRoute(
			name: "default",
			template: "{controller=Home}/{action=Index}/{id?}");
	});
}

GDPR (szerzej znane jako RODO)

Szablony projektu ASP.NET Core 2.1 zawierają kilka istotnych punktów startowych pozwalających na spełnienie unijnego rozporządzenia o ochronie danych osobych, GDPR. Używam tego pojęcia ponieważ w standardach korporacyjnych częściej spotkacie się z tym pojęciem niż RODO.

Nowa funkcjonalność pozwoli zapytać użytkownika o wyrażenie zgody na przechowywanie danych osobych i śledzenie go na stronie za pomocą mechanizmu ciasteczek. Jeżeli użytkownik nie wyrazi zgody na gromadzenie danych, nieistotne pliki cookie nie będą przesyłane do przeglądarki.

Jednym z interesujących nas plików jest: RODO w ASP.NET Core Plik ten pozwala m.in. na zdefiniowanie własnej polityki prywatności i zasad korzystania z ciasteczek. Dodatkowo w pliku Startup.cs sprawdźcie metodę:

public void ConfigureServices(IServiceCollection services)
{
	services.Configure<CookiePolicyOptions>(options =>
	{
		// This lambda determines whether user consent for non-essential cookies is needed for a given request.
		options.CheckConsentNeeded = context => true;
		options.MinimumSameSitePolicy = SameSiteMode.None;
	});
	services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}
Implementacja określa, czy dla danego żądania potrzebna jest zgoda użytkownika na ciasteczka inne niż istotne (niezbędne do działania naszej aplikacji).

Podsumowanie

W tej części artykułu to już wszystko. W szybkim wprowadzeniu skupiłem się w głównej mierze na bezpieczeństwie i prywatności naszych użytkowników. Pełną listę zmian możecie zobaczyć i prześledzić na blogu devblogs.microsoft.com