Asp.Net Core – o migracji z RC1 do RC2 słów kilka.

Siemanko.

Dziś kilka wskazówek jak podejść do próby migracji projektu z wersji RC1 do RC2. Celowo napisałem „próby” ponieważ nie ma pewności, że Ci się to uda 😉 Wszystko zależy od struktury Twojego projektu oraz od Twojej odporności na dziwne błędy uniemożliwiające kompilację, które nie są zgłaszane przez IDE. Subiektywnie podzieliłem operacje migracji na dwa przypadki:

  • kiedy masz tylko web application
  • kiedy masz web application z referencjami do class library packages

Oczywiście musisz mieć zainstalowany .NET Core. Możesz to zrobić instalując update w Visual Studio lub pobierając go tutaj.

Samo Web Application

W wersji RC1 web application było jednym template’em.

3

Template web application w wersji RC1

Na poziomie tworzenia należało wskazać czy ma to być aplikacji Asp.Net 5 czy poprzednia

4

Następnie w pliku project.json należało wskazać runtime (clr lub coreclr, lub oba).

W wersji RC2 mamy dwa template’y web application – jeden dla .NETu, a drugi cross platform

2

Proponuję Ci utworzyć odpowiedni template (jeśli w Twoja aplikacja RC1 jest cross platform i korzysta z dnxcore to wybierz .NET Core, jeśli z samego dnxa to .NET Framework). Przejdź do pliku global.json nowo utworzonej solucji, skopiuj sdk version i wklej w to samo miejsce w swoim projekcie RC1.

1.png

global.json w wersji RC1

 

 

1

global.json w wersji RC2

Oczywiście wersja sdk 1.0.0-preview1-002702 w RC2 jest taka na dzień pisania posta.

Przejdź do katalogu C:\Users\nazwa_usera i skasuj folder .dnx. Tak, skasuj. Dnxa już nie ma i wszystko co jest w tym folderze już nie jest potrzebne, a może tylko generować jakieś trudności.

Dostosuj swój project.json do tego, który jest w wygenerowanym nowym szablonie i zacznij zmieniać namespace’y paczek w sekcji dependencies. Tutaj musisz zdawać się na IDE i błędy, które zgłasza (np. namespace’y z AspNet trzeba zmienić na AspNetCore itp.). Jak już uda Ci się doprowadzić error list do pustki to przejdź do package manager console, a w nim do folderu aplikacji i wpisz dotnet restore. Powinny zacząć pobierać się wszystkie paczki nugetowe. Reaguj na błędy, restoruj paczki i tak w kółko do skutku 🙂 Zamknięcie Visuala i ponowne otwarcie jest jak najbardziej wskazane 😉

Web Application z referencjami do class library packages

Tu już jest gorzej ponieważ w RC2 nie ma tego wynalazku – class library package z niebieską ikonką i plikiem project.json

1.png

Class library dla Asp.Net Core w wersji RC1

Teraz mamy normalne „zielone” class library

1

Class library w wersji Asp.Net Core RC2

Jak widać na zdjęciu mamy także dwa typy class library – dla .NET Core i dla .NET Framework. Aby nasz projekt zabanglał w RC2 to niestety musimy utworzyć całkiem nowe class library i pokopiować do nich klasy oraz dodać wszystkie paczki nugetowe przez Nuget Package Manager (w poprzedniej wersji można to było zrobić w pliku project.json). Należy pamiętać aby zaznaczyć ckeckbox Include prerelease podczas wyszukiwania paczek.

Podsumowanie

Życzę Ci powodzenia i wytrwałości. Pamiętaj jednak, że zawsze możesz utworzyć całą solucję od nowa i pokopiować pliki, albo po prostu rzucić to wszystko i wyjechać w Bieszczady 😉

Pjona!

„Hub could not be resolved” czyli kwiatuszki w Asp.Net Core RC2

Siemanko.

Całkiem nie dawno pisałem o tym, że udało mi się przejść na wersję RC2 frameworka Asp.Net Core. Wersję, której żywot określono na krótko bo pod koniec czerwca ma wyjść już RTM. Z tego względu wydawałoby się, że jest to już dopieszczona wersja i wszystko jest w niej cacy… ale niestety.

Problemy z SignalR

W wersji RC1, w moim projekcie zacząłem się już komunikować poprzez SignalR między apką mobilną, a serwerem. Po upgrade’dzie projektu do wersji RC2 po chwilce przerwy przysiadłem znowu do pracy i ku mojemu zdziwieniu po próbie połączenia się apki z serwerem aplikacja mobilna się wywalała. Zapewne znasz to uczucie gdy nie zmieniłeś choć jednej linijki kodu, IDE nie sypie errorami, a coś co działało jeszcze wczoraj z niewiadomych przyczyn przestało. Po kilku godzinach prób zacząłem debugowanko na serwerze. W Sturtup.cs przed deklaracją SignalR zamieściłem kilka linijek kodu aby następne wywołanie na pipeline złapać w try catch:

1

Zacząłem googlować i doklikałem się do issue na githubie. Otóż w wersji RC2 popsuto coś co działało w RC1 😉

Workaround

Gość na githubie podsunął mi tymczasowe rozwiązanie. Otóż bug jest w klasie DefaultAssemblyLocator.cs, który został już poprawiony, ale znajduje się w paczce RC3 z referencjami do inncyh paczek RC3, które zarazem będą się gryzły z RC2Skopiowałem kod tej klasy i umieściłem go w swoim projekcie w nowo utworzonej klasie o nazwie HubCouldNotBeResolvedWorkaround (możesz nazwać jak chcesz). W Sturtup.cs w metodzie ConfigureServices tuż przed wywołaniem

services.AddSignalR();

należy umieścić linijkę 

services.AddSingleton<IAssemblyLocator, HubCouldNotBeResolvedWorkaround>();

Ten kod oznacza ni mniej ni więcej jak dla każdej zależności IAssemblyLocator wstrzyknij obiekt HubCouldNotBeResolvedWorkaround, który ma być singletonem w ramach całej aplikacji. W ten sposób IAssemblyLocator  z paczki SignalR RC2 z bugiem został zastąpiony poprawionym z wersji RC3 bez konieczności upgrade’u całego projektu do RC3 (która jest tylko na deweloperskich serwerach Nuget)

Podsumowanie

Mam nadzieje, że dzięki temu wpisowi zaoszczędzisz kilka godzin na kminienie co może być nie tak – tak jak ja.

Pjona!

Projekt Asp.Net Core po wielu godzinach przeniesiony do wersji RC2.

Siemanko

W sobotę napisałem, że zaczynam atakować mój projekt back’endowy w celu przeniesienia go na .NET CLI i wyswobodzenia go od skasowanego DNX’a – czyli przejście na oficjalną wersję RC2 frameworka. Nie trwało to kilka dni jakby wskazywał na to kalendarz, ale krócej bo właściwie znalazłem czas aby przysiąść do tego tylko trzy razy. Pierwszy raz był we wspomnianą sobotę i to posiedzenie zakończyło się moją klęską, i niezłym wkurwieniem ocierającym się o rezygnację z programowania i wzięcia się za grę w brydża 😉 Drugi raz był wczoraj wieczorem gdzie przyjąłem nieco inną taktykę, która także okazała się nieskuteczna jednak doprowadziła do wyklarowania się decyzji o utworzeniu nowej solucji wraz z nowymi projektami i przenoszeniu do nich klas z istniejącego projektu. Tym się właśnie zająłem dziś i mogę powiedzieć, że się udało. Projekt się kompiluje oraz uruchamia.

1

O tym co się zmieniło oraz najważniejsze – jak to przeniosłem – napisze po weekendzie. Teraz mogę Ci powiedzieć tylko tyle, że olej sobie dokumentację migracji przygotowaną przez ekipę Asp.Net Core. Opisuje ona różnice w plikach konfiguracyjnych i takie tam pierdololo, ale nie mówi jak przenieść istniejący projekt ASP.NET Core RC1 do ASP.NET Core RC2. Jak będziesz grzeczny to ja Ci napiszę 😉

Pjona!

Pierwsze podejście do upgrade’u projektu Asp.Net Core – from DNX to .NET Core Cli

Siemanko

Piękny, słoneczny dzień dziś (przynajmniej u mnie) dlatego postanowiłem sobie go nieco zjebać i spróbuje przenieść aplikacje serwerową do najnowszej wersji frameworka czyli Asp.Net Core 1.0 Rc2. Niby kolejny release candidate, ale kompletnie inny pod spodem. Cóż, ewolucja 🙂 Dam znać niedługo czy jest w ogóle możliwa migracja z Rc1 do Rc2 bez nowych siwych włosów i czy w ogóle się da. Microsoft’owe ludki twierdzą, że się da i nawet odziwo przygotowali do tego jakąś dokumentację. Wszystkiego możesz się dowiedzieć tutaj. Życz mi powodzenia 🙂

Pjona!

Jeśli nie ma czegoś w nugecie tzn., że to nie istnieje? Nuget to nie google i ma swoje package source.

Siemanko

W poprzednim poście napisałem, że będę próbował zupgradować projekt back endu do nieoficjalnej najnowszej wersji frameworka Asp.Net Core (RC2) tzw. nightly builds. Było to podyktowane tym, że chciałem zacząć pracę nad implementacją czatu dla użytkowników aplikacji mobilnej mojego projektu. Jeśli czat to sockety, a jeśli sockety i asp.net to SignalR. Niczego jeszcze nie robiłem z SignalR, ale kiedyś oglądałem jakiś kursik, gdzie m.in. była prezentacja SignalR dlatego od samego początku miałem w głowie, że właśnie z tym ustrojstwem będę się bawił robiąc czat.

Wracając do upgrade’u. Dlatego pisałem o potrzebie podniesieniu wersji frameworka bo w aktualnym RC1-final nie było paczki SignalR w kombatybilnej wersji

1

Screen z pliku project.json z sekcji dependencies

Lipa, nie? A przeglądając github’a widziałem przykłady SignalR, ale w wersji frameworka RC2, dlatego też ślepo przyjąłem, że w aktualnej wersji RC1-final po prostu nie ma SignalR.

Package Manager Source

Wszystkiemu winna (bądź nie) konfiguracja źródeł dla nugeta, a raczej informowanie zwykłych devów o adresach serwerów, z których można pobierać paczki publikowane prze teamy pracujące nad frameworkami, których Ci zwykli devowie używają 😉 Tym zakręconym zdaniem przechodzimy do głównego bohatera dzisiejszego posta czyli nuget.config.

2

3

To co widzisz powyżej to nic innego jak programowa prezentacja pliku nuget.config znajdującego się w dokumentach użytkownika

4

To jest chyba standardowa wersja ustawień nugeta tzn. ze standardowym źródłem. Teamy Asp.Net Core i ogólnie całego nowego .Net Core mają swoją serwery, na których publikują paczki , i z których zarazem my – prości devovie – możemy je ściągać 🙂 Szkoda tylko, że nie informują o tym w dokumentacji tylko trzeba zaglądać do pliku nuget.config każdego z projektów na github’ie.  W moim przypadku dodanie źródła o adresie

https://www.myget.org/f/aspnetmaster/api/v3/index.json

poskutkowało pojawieniem się paczki SignalR w odpowiedniej dla mnie wersji

6

Podsumowanie

Jeśli nie możesz czegoś znaleźć w nugecie to nie zakładaj, że tego tam nie ma albo, że zjebało Ci się Visual Studio 😉 Niech Twym pierwszym działaniem będzie upewnienie się czy masz odpowiednie źródła wpisane do nuget.config. 

Pjona!

Wracam po tygodniu przerwy. Podsumowanie dwóch miesięcy pracy nad projektem „Mobile Second Hand”

Siemanko

Chciałbym sobie schlebić i napisać, że pewnie zauważyłeś/łaś przerwę w moim blogowaniu oraz commitowaniu do repo na tydzień, jednak stąpam twardo po ziemi i godzę się z tym, że oprócz mnie samego nikt zapewne nie dostrzegł tej ogromnej luki w polskim internecie 😉 Jeśli jednak chcesz się ujawnić i pochwalić, że należysz do, bądź co bądź, elitarnego grona czytelników (jak czegoś mało tzn., że nie dla wszystkich ;)) to daj znać pod spodem. W dzisiejszym poście podsumowanko dwumiesięcznego blogowania i kodowania.

Staty z wodpressa

Nie wiem czy to śmiesznie mało, czy normalnie jak na początek, ale na dziś tj. 04.05.2016 wordpress zanotował przez niewiele ponad dwa mieisące 794 wyświetlenia i 439 gości na blogu.

1

Blogowanie

17 postów konkursowych i 2 posty niezwiązane z #dajsiepoznac opublikowane zaraz po stworzeniu bloga, ale jeszcze przed startem konkursu. Staram się nie pisać żadnego pierdololo, by tylko spełnić wymóg dwóch postów tygodniowo, dlatego przyjąłem zasadę: najpierw kodowanie potem blogowanie, aby mieć się czym dzielić. Posty publikuje w regularnych odstępach czasu w te same dni tygodnia – środa i niedziela.

Kodowanie

Android Studio – moim zdaniem bardzo young developer friendly środowisko. Wiele gotowych template’ów z których, świeżaki mogą szybko wgryzać się w Androida. Fajne funkcjonalności wspomagające refaktoryzację kodu i wiele innych.

Java – podobna do C#. W przypadku potrzeby przebranżowienia powinno pójść gładko

Asp.Net Core 1.0 – wersja RC1-final. Wszystko spoko. Wszystko wskazuje na to,  że będą musiał zrobić upgrade do wersji RC2 nightly builds ponieważ, chcę skorzystać z SignalR do zrobienia chatu dla userów aplikacji mobilnej. Mam nadzieję, że pójdzie w miarę gładko

Entity Framework Core 1.0 – trzeba zapomnieć o sposobie pracy z EF6. Brak automatycznej konfiguracji relacji wiele do wielu, kaskadowy zapis nie zawsze działa, usuwanie obiektów z kontekstu nie odzwierciedla się nigdzie do momentu wywołania SaveChanges(), bugi przy self reference i wiele innych ciekawostek. Zobaczę co poprawili w wersji RC2 jeśli uda mi się zupgradować projekt

Xamarin – fajne środowisko. Trochę wolne, ale .NETowe dobroci rekompensują wszystko. Przyspieszyłem z aplikacją mobilną od momentu rozstania z Android Studio, a kod jest dużo bardziej schludny i czysty.

Podsumowanie

Na pewno nie uda mi się skończyć projektu przed końcem konkursu. Im głębiej w las tym więcej chciałoby się funkcjonalności, a co za tym idzie jest więcej roboty przy niezmiennie małej ilości wolnego czasu. Po konkursie będę na pewno dalej pracował nad projektem. Czy blogował? Na pewno nie dwa razy w tygodniu, ale może raz na jakiś czas opowiem jakiś dowcip 😉

Pjona!

Rozpoznawanie kategorii i koloru z tekstu ogłoszenia oraz pierwsze testy jednostkowe w Asp.Net Core 1.0

Siemanko

Jak już wcześniej wspominałem aplikacja mobilna nie będzie wymagała deklarowania kategorii czy koloru ubrania w momencie tworzenia nowego ogłoszenia. Niewątpliwie te dane byłyby bardzo przydatne w celu filtrowania wyników wyszukiwania oraz przy Machine Learning, które miałoby ogarniać najchętniej przeglądane ciuchy przez użytkownika w celu podpowiadania mu tego co mogło by go zainteresować (jeszcze nie ruszyłem z ML, ale mam to w planach ;)). Tą robotą zajmie się system.

Słowniki ze słowami kluczowymi dla kategorii i koloru

Wyrażenia regularne nie wchodzą w grę ponieważ nazwy kategorii i kolorów są przeróżne, więc dla każdej opcji musiałbym napisać oddzielne wyrażenie co przy późniejszej potrzebie modyfikacji okazało by się, że to niezły pain (nie wkurzają Cię te moje angielskie bądź pseudo angielskie wcinki? ;)). Dlatego wymyśliłem to najprościej jak mogłem i opiszę to na przykładzie kategorii.

2

Fragment słownika kategorii

Kluczem jest początek nazwy kategorii, a wartością lista słów pasujących do wzorca z klucza wraz z różnymi odmianami, przy czym pierwszym elementem jest zawsze słowo kluczowe, które będzie wiązane z ogłoszeniami. Taki słownik będę mógł zawsze zmodyfikować dodając kolejne klucze bądź rozszerzając listy wartości dla klucza. Jedynym ograniczeniem będzie tylko to, że nie będę mógł zmienić pierwszych elementów z list wartości bo te będą mogły być już zapisane w bazie.

Rozpoznawanie kategorii i koloru

Najlepiej będzie jak rzucisz okiem na kod.

3

Lecę foreach’em po kluczach danego słownika i sprawdzam czy zawiera się on w tekście ogłoszenia. Jeśli tak to lecę kolejnym foreach’em po wartościach dla danego klucza i sprawdzam czy którykolwiek ze stringów znajduje się w tekście. Jeśli tak to do listy wynikowej przypisuje pierwszy element z listy wartości. W ten sposób wyłapuje hasła kluczowe, które potem są wyciągane z bazy lub zapisywane jeśli jeszcze takich nie było, a następnie wiązane z ogłoszeniem.

Side Waffle, XUnit i Moq – czyli ostre testowanko 😉

Aby sprawdzić czy to co opisałem wcześniej rzeczywiście działa postanowiłem wreszcie napisać pierwsze unit testy. Do tego celu doinstalowałem sobie do VS extension’a Side WaffleJest to paczka z ogromem różnych templatów, o których nie będę pisał prócz jednego – xUnit.

3

Jest to już skonfigurowany pod DNXa projekt testowy z xUnit. Od razu można jechać z testami. Co bardzo ważne – aby uruchomić napisany test trzeba otworzyć Test Explorer’a i zbudować projekt – w innym przypadku VS nie ogarnie, że są jakieś testy.

4

Przykładowy teścik

Nie jestem jakimś szpeniem od testów, ale dzięki dobrociom od xUnit takim jak [Theory], pisząc 18 testów w rzeczywistości mam przetestowane 83 przypadki.

Podsumowanie

Dzięki testom jednostkowym dla rozpoznawaczki słów kluczowych wyłapałem kilka błędów już na etapie jej pisania, które szybciutko poprawiłem 🙂

Unit testy są cool!

Pjona!

Xamarin’owa apka doprowadzona do stanu jaki prezentuje w Android Studio.

Siemanko.

Dziś króciutko.

W dniu dzisiejszym udało mi się doprowadzić aplikację mobilną do stanu jaki prezentowała w Android Studio w momencie podjęcia decyzji o przesiadce na Xamarin’a, więc nareszcie będę mógł jechać z nowymi tematami. Nie zliczałem czasu, ale szacuję, że zajęło mi to ok 20 godzin. Biorąc pod uwagę, że nie miałem wcześniej z Xamarin’em nic wspólnego to myślę, że to dobry wynik, a przyjemność jaką sprawia mi pisanie w nim jest o wiele większa niż w Android Studio. Ostatnie posty nie dotykały funkcjonalności rozwijanych w projekcie dlatego pozwolę sobie przypomnieć Ci co jest zrobione i za co zabieram się od jutra (dziś już dość kodzenia ;)).

Jest zrobione (zarówno po stronie aplikacji mobilnej jak i na serwerze):

  • autentykacja za pomocą tokena JWT (logowanie/rejestracja za pomocą formularza lub facebooka)
  • ustalanie lokalizacji w aplikacji mobilnej
  • pobieranie listy ogłoszeń na podstawie lokalizacji użytkownika uderzającego do API z uwzględnieniem zadeklarowanego przez niego obszaru z jakiego chce zobaczyć ogłoszenia (na podstawie zadeklarowanego promienia – wszystko wyliczam na serwerze)
  • tworzenie nowego ogłoszenia wraz ze zdjęciem i zapis do bazy na serwerze co skutkuje natychmiastowym pojawieniem się ogłoszenia w systemie

Co będzie robione:

  • predefiniowane hasła kluczowe dotyczące rodzaju ubrania (np. sukienka, bluzka itp.) oraz koloru, które będę wyłapywał na serwerze z tytułu i opisu ogłoszenia aby następnie je powiązać z sobą powiązać. W aplikacji nie będę wymagał wybierania ręcznego kategorii, itp. jak to jest np. na Allegro. Ma to być maksymalnie proste dlatego przypisywaniem haseł zajmie się system.
  • pobieranie listy ogłoszeń z zawężeniem do predefiniowanego hasła (np. tylko ogłoszenia ze spodniami)
  • powiadomienia w tle o pojawieniu się nowych ogłoszeń w zadeklarowanym przez usera obszarze
  • wyświetlanie szczegółów ogłoszenia po kliknięciu go na liście
  • komunikacja między użytkownikami systemu (kupujący – sprzedający)

Podsumowanie

Cieszę się, że będę już mógł pracować nad nowymi rzeczami, a nie odgrzewać stare kotlety ;). Jeśli Ty też się cieszysz moim szczęściem to daj feedback ;). A jeśli nie – to nie ;p

Pjona!

Kilka słów o EF Core 1.0

Siemanko.

Dziś troszkę o EF Core 1.0 (EF 7 do niedawna), które wykorzystuję w projekcie Asp.Net Core jako część backend’u dla aplikacji mobilnej Mobile Second Hand. Troszkę, bo nie poznałem jeszcze wszystkich nowości w tej wersji Microsoft’owego ORM’a i to co dziś przeczytasz będzie to głównie opis największych różnic między w.w. wersją, a poprzednią czyli EF6.

Gotowiec Entity Framework Identity.

Jak kiedyś wspomniałem, projekt Asp.Net Core założyłem z wbudowanego w Visual Studio template’a – Web Aplication – z zaznaczoną opcją Individual User Accounts co skutkuje tym, że z automatu jest skonfigurowany dostęp do danych wraz z obsługą autentykacji. Wystarczy tylko w pliczku appsettings.json głównego projektu wpisać connection string do bazy, z którą chcemy pracować. W moim przypadku:

q

Tak jak w poprzedniej wersji Entity Framework, jeśli baza podana w connection stringu nie istniała, wystarczyło utworzyć nowy obiekt DbContext’u aby ORM tę bazę utworzył, dlatego poszedłem tym samym tropem – utworzyłem obiekt Usera i spróbowałem zapisać. Niestety ku mojemu zdziwieniu nic z tego nie wyszło. Dostawałem wyjątek, że EF nie może się zalogować do serwera bazy danych z wykorzystaniem poświadczeń podanych w connection stringu. Było to tym bardziej frustrujące bo logowanie do SQL’a mam domenowe i tak też podałem w connection stringu. Po pewnym czasie i paru chujach skierowanych w stronę monitorów doszedłem do tego, że trzeba się ręcznie upewnić o istnieniu bazy i wtedy EF Core ją utworzy jeśli jej nie ma. Należy to zrobić wpisując jedną linijkę na końcu metody Configure w klasie Startup.cs.

2

Oczywiście context to nazwa parametru dla DbContext’u aplikacji jaki przyjmuje metoda Configure (dlatego równie dobrze może być dupa.Database.EnsureCreated()), a owy DbContext jest wstrzykiwany z użyciem Dependency Injection.

Brak Initializer’ów.

W poprzedniej wersji EF do współpracy z DbContext’em były definiowane i wykorzystywane tzw. Initializer’y. To one określały co ma się dziać z bazą danych. I tak:

  • CreateDatabaseIfNotExists – tworzył bazę gdy jej nie było – dlatego w poprzedniej wersji EF baza była z automatu tworzona gdyż ten Initializer był domyślny
  • DropCreateDatabaseIfModelChanges – usuwał i tworzył bazę gdy uległ zmianie, którykolwiek z modeli podanych w DbSet’cie
  • DropCreateDatabaseAlways – za każdym uruchomieniem aplikacji i jej pierwszym odwołaniu się do bazy ta była usuwana i tworzona na nowo
  • CustomDbInitializer – możliwość napisania swojego gdy żaden z powyższych nie odpowiadał (np. migracja do najnowszej wersji bazy w przypadku korzystania z ręcznych migracji)

Oczywiście wykorzystując te initilizer’y mogliśmy wypełniać bazę jakimiś danymi, ale to było w poprzedniej wersji. Teraz są tylko ręczne migracje.

Tylko ręczne migracje

W poprzedniej wersji mogliśmy nie korzystać z migracji, włączyć automatyczne migracje bądź ręcznie migrować schemat bazy. Teraz nie ma takiego wyboru i jedynym dostępnym sposobem do obsługi schematu bazy są ręczne migracje. Migracjami operujemy z poziomu command line’a. W projekcie głównym muszą być zainstalowane EntityFramework.Commands, aby można było ich używać w wierszu poleceń (w gotowej aplikacji z template’a już wszystko jest). Jeśli masz w solucji kilka projektów to musisz pamiętać aby za pomocą cd przejść do projektu głównego, gdzie są zainstalowane EntityFramework.Commands oraz koniecznie wpisać dnvm use 1.0.0-rc1-final (póki jest jeszcze wersja RC1 frameworka Asp.net Core) bo zacznie sypać wyjątkami, jeśli spróbujesz korzystać z komend EF np. dnx ef –help.

Podsumowanie

Tak jak wspomniałem we wstępie to tylko pierwsze spojrzenie na nową wersję EF. Jeśli jesteś ciekaw jak od zera dodać do projektu nowe EF to odwiedź matczyną stronę Asp.Net Core gdzie jest wszystko elegancko opisane.

W niedzielę napiszę o pierwszych walkach z Xamarinem ponieważ jak możesz się dowiedzieć z poprzedniego postu porzuciłem projekt w Android Studio i zaczynam od zera w Xamarinie.

Pjona!

MobileSecondHand – autentykacja po stronie serwera cz. 2.

Siemanko.

Dzisiaj druga część o autentykacji po stronie serwera. W części pierwszej napisałem, jak wygląda proces autentykacji za pomocą tokena, a dziś o tym jak i kiedy go generuje.

Przy tworzeniu nowej aplikacji webowej Asp.Net Core 1.0 z template’u w VS 2015 z automatu jest zaznaczona opcja indywidualnych kont użytkowników w sekcji autentykacji. Skutkuje to dodaniem do projektu paczki „Microsoft.AspNet.Identity.EntityFramework” (wraz z zależnościami), utworzeniem pierwszej migracji z tabelami związanymi z userami, oraz kontrolerów ze wstępnymi logikami do rejestracji, logowania i zarządzania kontem użytkownika. Żeby nie wywarzać otwartych drzwi oczywiście skorzystałem z tych dobrodziejstw w moim projekcie (po swojemu). Także przy tworzeniu oraz szukaniu usera w bazie korzystam z wbudowanych serwisów UserManager<T> oraz SignInManager<T>. Za pomocą ich metod mogę zapisać użytkownika do bazy, pobrać go, sprawdzić czy hasło jest prawidłowe itp.. Ogólnie sporo roboty do przodu.

Rejestracja i logowanie standardowe.

Rejestracja i logowanko sprowadza się do odebrania view modelu, wywołania odpowiednich metod z wcześniej wspomnianych serwisów i zwróceniu tokena.

1

2

3

Na ostatnim screenie jest metodka tworząca i zwracająca token. Odpowiedzialny za całe zamieszanie jest JwtSecurityTokenHandler z przestrzeni nazw System.IdentityModel.Tokens.Jwt.

Rejestracja i logowanie z facebookiem

Token autentykacji od fejsa pobieram w apce mobilnej i opisałem to w tym poście. Następnie token ten wysyłam na serwer gdzie napisałem sobie web clienta, który uderza do api facebooka w celu pobrania adresu emial potrzebnego do identity aplikacji serwerowej. Jednocześnie sprawdzana jest ważność facebook’owego tokenu. Cała klaska na dzień dzisiejszy wygląda tak:

4

Odpowiedzią api facebook’a jest oczywiście Json’ik. Parsuje go na swój obiekt odpowiedzi za pomocą JavaSrciptSerializer  z assembly System.Web.Exensions (bardzo fajna sprawa, rozwiązał mi problem błędnego parsowania tablicy byte’ów po stronie aplikacji mobilnej o czym w następnym poście). Swój obiekt odpowiedzi puszczam dalej i dzieje się to samo co na wcześniejszych screenach.

Pobieranie UserId z tokena

Po wpuszczeniu użytkownika do kontrolera przez JtwBearerTokenMiddleware wyciągam id usera z obiektu Identity  dostępnego przez wpisane User.Identity w kontrolerze. Do tej operacji napisałem serwisik zwracający mi id usera.

5

Podsumowanie

Autentykacja na takim poziomie jakim jest teraz w zupełności mi wystarcza aby w jak najmniejszym stopniu obciążać usera podawaniem swoich danych podczas korzystania z apki. W następnym poście wracamy do części androidowej i pobawimy się trochę z ogłoszeniami, czyli przeznaczeniem całego projektu :).

Pjona!,