Logowanie przy pomocy Facebook, Twitter czy Google – OWIN Katana na ASP MVC 5

2016/02/09 ~ Jarosław Stadnicki ~ 2 Comments

Następny wpis, tym razem już na nowym systemie i nowej własnej domenie. Zobaczymy czy będzie tak jak z samochodami, gdzie wizyta na myjni daje dwa konie mechaniczne więcej. Ostatnio pisałem więcej filozoficznie, dzisiaj powrót do twardej rzeczywistości.

Obejrzałem nie dawno na pluralsight fajny i krótki kurs o OWIN i Katana i częścią wiedzy chce się z wami podzielić.
Kto z was zaczynał projekt ASP MVC z włączonymi indywidualnymi kontami użytkowników? Ja na pewno! Także ja, gdy patrzyłem co się dzieje w OWINIE (w części konfiguracyjnej) i AccoutController łapałem się za głowę i zastanawiałem się WTF? Oczywiście próbowałem zrozumieć o co tam chodzi i czemu to wszystko jest tak “fajnie” napisane, niestety nie starczyło mi na to nigdy cierpliwości. Koniec końców pogodziłem się z tym faktem i korzystałem z tego tak jak jest, działało a ja nie zadawałem pytań – sprzedawać!

Teraz to wszystko może się zmienić! (dramatyczna muzyka i suspens – teraz!)

Aby to wszystko zrozumieć, zacząć należałoby od stworzenia pustego projektu MVC5 (tak, wiem staroć) – żadnych dodatkowych referencji, nic! Jak się bawić to na trylion procent. Na koniec wpisu, znajdziecie link do całego projektu. Dodajemy samodzielnie referencje do OWINowych rzeczy, tak aby moje i wasze referencje w tej kwestii się zgadzały:

Microsoft.Owin
Microsoft.Owin.Host.SystemWeb
Microsoft.Owin.Security
Microsoft.Owin.Security.Cookies
Microsoft.Owin.Security.Facebook
Microsoft.Owin.Security.Google
Microsoft.Owin.Security.Twitter

Z racji tego że projekt będzie oparty o MVC, nie można zapomnieć o:

System.Web.Mvc

Gdy to mamy ogarnięte, warto dodać plik z punktem wejścia do aplikacji, wykorzystany zostanie także do konfiguracji facebooka, twittera czy G+ oraz ogólnej authentykacji, u mnie wygląda on tak:

Co tam ciekawego? Na początku (@14) informujemy aplikację, o chęci korzystania z autentykacji opartej o ciastka. Ciastko przenosząca tajne dane nazywamy ThisCanBeAnythingYouLike. Następnie (@20-@41) wpinamy kolejne warstwy umożliwiające użytkownikom logowanie się przy pomocy FB, Twittera czy G+. Należy podać sekretne kody jednoznacznie identyfikujące waszą aplikacje.

Uwaga (@32) tutaj null oznacza, że nie interesuje mnie walidacja certyfikatów Twittera, oznacza to nie mniej, nie więcej, że jeśli ktoś podszyje się do Twittera i sprzeda mi swój certyfikat, ja to łyknę jak młody pelikan. Taka zagrywka przejdzie na blogu. Na żywej produkcji, należy odnaleźć aktualnie używane certyfikaty Twittera i dodać jest do walidacji. Dodatkowo zwracam uwagę, że wszystkie formy authentykacji korzystają z tego samego ciastka, znowu na blogu nie robi mi to różnicy skąd i jak i czym logują się moi użytkownicy. Produkcja rządzić może się swoimi prawami.
“/Auth/Login” (@14) ta linijka mówi, gdzie należy się przekierować gdy użytkownik nie będzie zalogowany, a aplikacje będzie tego wymagać.
Dla przypomnienia odpowiednio atrybuty AllowAnonymousAttribute oraz AuthorizeAttribute.

Skoro już powiedziałem o przekierowaniu do “/Auth/Login” (Auth controller, Login action) zajrzyjmy co kryje się w tej klasie:

Wielkiej ilości kodu nie ma (gdzie jest AccountController?!). Zaczynając od metody [HttpGet]Login (@15) tworzymy prosty pusty model do logowania się użytkownika. Z OWINa wyciągamy informacje o zarejestrowanych providerach (dostarczycielach?) logowania i wpychamy do modułu, który potem renderujemy.

W parach pracuje się lepiej, dlatego istnieje także [HttpPost]Login (@29) który przyjmuje ten sam model(pamiętamy, że to tylko wpis na blogu i nie maiłczymy że model!=dto!=viewmodel). W klasie są informacje o nazwie i haśle, następuje skomplikowana weryfikacja i jeśli dane są poprawne tworzymy w locie użytkownika. Nadajemy mu także pewne cechy: nazwę oraz identyfikator. Tak zdefiniowanego użytkownika logujemy przy wykorzystaniu OWINa. I wracamy do domu, jeśli weryfikacja się nie powiedzie, dajemy kolejną szansę.

Dla znudzonych oferujemy opcję wylogowania (@47) jak zawsze wszystko kręci się wokół OWINa.

Wreszcie! WRESZCIE! Jak zobaczycie zaraz na przykładzie z razora, tutaj obsługujemy kliknięcie użytkownika, gdy wybierze ono (!on i !ona) opcję logowania się przy pomocy FB, Twitter czy G+. Jako parametr wejściowy przyjdzie nazwa providera. Następnie na OWINie i autentykacji wywołujemy metodę Challange z parametrem informującym, że chcemy wrócić do “/secret”. Kod tego kontrolera pokaże na końcu. Po wywołaniu zwracamy jeszcze odpowiedni kod HTTP aby wszystkim formalnościom stało się zadość. Status Unauthorized jest bardzo ważny i nie może zostać pominięty.

No dobrze, skoro tutaj tak mało kodu, to pewnie razor będzie przekombinowany, pomyślało teraz ono. Aby nie trzymać w niepewności:

Pierwsze linie wynikają z braku pełnej integracji z MVC, odpowiednich wpisów w web.config etc. Ignoruj. Linie (@15-@30) to forma gdzie można się zalogować jako aplikacyjny użytkownik. Linie (@32-@37) to pętla, która wyciąga z modelu (ono przypomina sobie teraz AuthController::Login) listę providerów, na jej podstawie tworzy proste linki z nazwą providera oraz odpowiednim id (“Facebook”, “Twitter”, “Google”), które zostanie przekazane do metody SocialLogin (AuthController::SocialLogin) i użyte to rozróżnienia providera.

Co teraz? Gdzie jest reszta, gdzie jest ACCOUNTCONTROLLER? Nie ma i nie potrzeba. Póki co, nie będę nigdzie zapisywać użytkowników. Demo pokazuje tylko jak zalogować się przy pomocy providerów wymienionych powyżej.

Co znaczy zalogowanie? Otóż mniej więcej tyle:

Będziemy w stanie przejść do metody Index, która jest klasie wymagającej autoryzacji. Czyli User.Identity.IsAuthenticated zwróci TRUE. To całkiem fajnie. Oprócz tego, mamy kilka dodatkowych informacji:
Oraz widok:

W widoku widać że interesują nas cechy nadane nam przez system. Nie ważne czy to FB, Twitter, G+ czy my sami (AuthController, Login w wersji POST). Po uruchomieniu aplikacji wynik operacji wyglądają tak:

Wersja lokalna (user:jaroslaw/pass:stadnicki):

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier : jaroslaw
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name : jaroslaw

Wersja z G+

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier : 1#6#9#9#9#2#4#7#1#2#6 (odrobina prywatności)
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname : Jarosław
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname : Stadnicki
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name : Jarosław Stadnicki
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress : jaroslaw.stadnicki@gmail.com
urn:google:profile : https://plus.google.com/+JarosławStadnicki

Itp, itd. Warto zwrócić uwagę, że z G+ (inne też), dostajemy już identyfikator użytkownika, który możemy powiązać ze swoim lokalnie tworzonym kontem. I gdy ponownie przyjdzie gościu z G+ i się zaloguje się i dostaniemy jego ID, będziemy wiedzieć, że on to on, a nie ktoś inny.

Na koniec jeszcze ważna sprawa, oczywiście należy pamiętać aby samodzielnie stworzyć swoje aplikacje odpowiednio na stronach:
https://developers.facebook.com/
https://apps.twitter.com/
https://console.developers.google.com/home/dashboard

Należy także ustawić poprawnie callbacki w tych systemach, u mnie wartość które działały poprawnie to: http://www.xoxox.com

Ej, ale co to za dziwny adres? No tak tak, bo Twitter nie lubi localhost (FB i G+ sobie z tym radzą). Dlatego dla Twittera robi się wyjątek i należy zaatakować windows\sytem32\drivers\etc\host dopisać taką linijkę:

127.0.0.1 www.xoxox.com

Od tej pory www.xoxox.com będzie wskazywać na wasz komputer. Ale jeszcze! Należy na normalnym IIS dodać stronę i pokazać jej, że binarki leżą u was w źródłach. Dodać binding w IIS. I na końcu w Visual Studio przełączyć się z IIS express na normalnego i też korzystać z www.xoxox.com. Można też zignorować twittera i dla testów sprawdzić tylko FB i G+ i korzystać z IIS express na 127.0.0.1

Tyle, od tej pory ja i wy (jaka jest liczna mnoga od ono?) będziemy mogli w prosty sposób logować się społecznościami. Aplikacja dostępna jest pod linkiem:
https://bitbucket.org/jstadnicki/simplesociallogin

Kod do aplikacji zostały zmienione przed publikacją, także aby zadziałały należy wygenerować własne oraz podmienić. Projekt działa pod kontrolą pełnego IIS, to także należy/można zmienić.

To tyle. Życzę miłej zabawy.

Bardzo prost logi w asp mvc

2016/01/17 ~ Jarosław Stadnicki ~ Leave a comment

Nigdy nie ciągnęło mnie do logowania. Zawsze miałem problem z określeniem poziomu na jaki zasługiwała dana informacja, a może ostrzeżenie. Czy to błąd, czy to już krytyczny błąd. Jak mam to dobrze zalogować. Czemu te okrutne logi tak strasznie mieszają mi się w aplikacje, wtedy jeszcze nie znałem podejścia AO.
Pisanie własnego logera też nigdy nie sprawiało mi przyjemności, zawsze czułem że robię coś nie tak. Jak już poznałem nloga czy log4net i próbowałem go zaprząc do aplikacji, to konfiguracja jednego i drugiego też zawsze szła po gruzie. Summa summarum życie szło powoli, a z logów nie korzystałem i nadal nie najczęściej nie korzystam (czasem żałuje). W projektach dziedziczonych logowanie już jest i wszystko jest już ustawione i postanowione i tak ma być – a że wszyscy referują do logera, to też jest “spoko”. Ale nie o tym miałem pisać. Często się zdarza, że mi tego brakuje i wtedy albo na chwilę dodaje logowanie, a potem usuwam, a potem jak znowu potrzebuje to usuwam, albo zostawiam bo może kiedyś mi się przyda i strasznie mnie to wkurza. Dlatego gdy odkryłem tracing musiałem się tym podzielić. Otóż taram taram – ( dla części z was oczywista oczywistość), w asp.net mvc jest wbudowane proste tracowanie, które spełnia moje podstawowe wymagania i włącza się to niebotycznie prosto.

Wystarczy tyle, żeby móc przejść na stronę myWebApp/trace.axd i móc oglądać szczegóły request’ów, które otrzymuje aplikacja. Jest tam więcej przełączników, które można poznać na internecie, np. na msdn.
Oto co dostajemy za darmoszke:

Faking hel – i to praktycznie za darmo?! Oczywiście możemy dorzucać trochę swojego logowania jeśli trzeba robi się to przez taką linikę kodu:
HttpContext.Trace.Write(“Category”, “Text to log”);
Dodatkowe wpisy znajdą się w sekcji TraceInformation. Dla mnie bóstwo. Włączyć, dodać kilka linijek w kodzie na szybko, sprawdzić i wywalić.
Podobną funkcjonalność można uzyskać przy pomocy Glimpse – też wypas. Jeszcze inna opcja to F12 developers tools w każdej przeglądarce, ale tam nie dostaniemy informacji o stanie serwera. No i tyle, krótko i na temat.

.net developers days – myśli zebrane

2015/10/21 ~ Jarosław Stadnicki ~ Leave a comment

Tym razem udałem się do warszawy na konferencje .net developers days i zrobiłem sobie słit focie ze Scottem – yey! yey! yey!

Wiem, mam zamknięte oczy (smuteczek) Ale! Ze Scottem!!! Mam jeszcze jedno, ale tak niewyraźne, że nie uwierzycie że to ja.

A teraz część z myśli, które zebrałem słuchając różnych wykładów i rozmyślając też o różnych rzeczach podczas słuchania:

Nie mieszać klas które służą do czystego przechowywania danych oraz tych, które na nich operują. Powinno to ułatwić skalowalność systemu, utrzymanie systemu, jest też spora szansa na to że system stanie się mniej stanowy, a przez to mniej awaryjny.

Value objects z DDD to fajna sprawa, nawet jeśli nie korzysta się z pełnego dobrodziejstwa które oferuje ddd, to warto wprowadzić przynajmniej część. Duża zaletą jest to że string który może się kryć z User.Firstname oraz User.Address i który normalnie możemy ze sobą porównać, nagle stanie się nie porównywalny ponieważ stringa ukryjemy w klasie UserAddress, a stringa odpowiedzialnego za Firstname ukryjemy w klasie UserFirstname i pomimo tego że w środku są to stringi, to dla kompilatora będą to dwie zupełnie inne typy, przez co nie da się ich ze sobą porównać. Dodatkową zaletą jest to, że podczas definiowania parametrów metody, czytelniej będzie czytać foo(UserFirstname name, UserAddress address){…} niż foo(string name, string address){…}

Dostając projekt, wymagania, nowego klienta, etc możemy się wkurzać na wiele rzeczy, naprawdę wiele. Ale warto sobie zdać posiedzieć przez chwilę i pomyśleć. Znaleźć wszystkie rzeczy, które są dla nas/was/mnie denerwujące, następnie podzielić je na dwie grupy: 1-mogę to zmienić, 2- nie mogę tego zmienić. I teraz wszystkie dwójeczki lądują w kuble, skoro nie można tego zmienić, to się trzeba przyzwyczaić. A wszystkie 1 lądują na naszej tapecie i robimy tak, żeby było lepiej. Do dwójeczek nigdy nie wracamy i godzimy się z losem jaki nas/was/mnie spotkał. Podobną myśl powiedział mi kiedyś znajomy, nie przejmuj się rzeczami na które nie masz wpływu – świetnie działa.
Wszyscy jesteśmy ludźmi i musimy się pogodzić z tym, że czasem coś nam nie wyjdzie – musimy się z tym pogodzić. Nie warto zakładać, że wszystko co robimy skończy się spektakularnym sukcesem i nie każdy z nas skończy tak jak Marek Zuckerberg czy inne Grycanki. Czasem słońce, czasem deszcze – takie jest życie.

Jeśli prowadzicie retrospekcje, gdzie programiści mogą się spotkać i porozmawiać o tym co się udało, co było dobre, co się sprawdza, ale i to co się nie udało, co złe, co się nie sprawdza (patrz punkt poprzedni). To samo dotyczy menadżerów projektu, oni także mają swoje przemyślenia (tak tak, oni też myślą). Jeśli macie takie spotkania, to może warto aby podzielić się decyzjami, przemyśleniami, ustaleniami, próbami, sukcesami i porażkami z resztą ludzi którzy z wami pracują w firmie. W ten sposób, może udało by się ustrzec przed najczęstszymi błędami, może decyzje które podejmujecie na nowy sprint okażą się nie najlepsze, ponieważ inny zespół już próbował, a może dostaniecie wskazówki na co warto zwrócić uwagę próbując nowego rozwiązania. Dzielenie się wiedzą jest sexi!

Input w obiekcie na poziomie konstruktora – ? Co ja miałem na myśli? Walidacja? Zagadka – stawiam że tak. Jak sobie przypomnę to dopiszę.
Breakstorming – fajna pomysł nie tylko dla testerów. Pracujecie w zespole? Spotkajcie się od czasu do czasu, ale nie za rzadko i zróbcie sobie code review, gdzie główną ideą jest zepsucie kodu innego kolegi; na zasadzie: pacz Stefan, jak wyślę takie parametry i wystąpi taki warunek, to twój serwis rzuca wyjątkiem. Można wymyślać najbardziej złośliwe ścieżki, najmniej prawdopodobne do spełnienia, etc. Chodzi o możliwie najefektywniejsze wysadzenie jeźdźca z siodła

Aplikacje webowe powinny być w stanie “zadziałać” bez połączenia z serwerem. Tak! Chodzi oczywiście o aplikację którą mamy już u nas, lub o taką która zaciąga statyczne html plus javascript, natomiast mięsko kryje się gdzieś głęboko na serwerach. Wtedy zamiast rzucania magicznymi kodami błędów, użytkownik powinien być w przyjazny sposób poinformowany, że nie da rady teraz wykonać tego trudnego zadania. Ale może popatrzeć na nasz spinner czy coś, który mówi: wiemy że nie działa i walczymy, próbuj dalej.
Nie ładować konfiguracji podczas wykonywania kodu – już spieszę ze szczegółami. Chodzi o przypadek, gdy ustawienia miałby być ładowane przez samą metodę podczas wykonywania kodu. Czyli mogłoby dojść do sytuacji, że metoda foo(“jarek”, “wrocław”){…} raz wykona logikę_1 a raz wykona logikę_2, ponieważ pomiędzy poszczególnymi wywołaniami metod, plik z konfiguracją został zmieniony i teraz zachowuję się inaczej. Prowadzi to do niespójności w aplikacji. Konfiguracja powinna być zaczytana raz na początku działania aplikacji i tyle. Aby zmienić ustawienia, należy wykonać restart aplikacji.

Dlannybecon – nie mam pojęcia co napisałem na kartce ^.^
Robiąc sobie zdjęcie ze Scottem :):):):) patrz na górze, doszły mnie słuchy, że przygotowywane są learniing box dla nowego asp i mvc na poziomie novice, regular, master – i powinny być oficjalnie dostępne w styczniu 2016 roku. Mają umożliwić samokształcenie jak i przygotowanie sesji dla innych ludzi. Wersje novice są chyba na mva. Nie szukałem więc nie posiadam linka.

Klasycznie czekam na komentarze lub nie zgody z moim rozumowaniem. Chętnie przyznam się do błędu jeśli taki popełniłem.

ps.

Poznałem fajny podcast:

www.codingblocks.net

Autofac update – dynamiczna zmiana implementacji

2015/04/19 ~ Jarosław Stadnicki ~ Leave a comment

Wiadomo, że każdy projekcie są testy. W części z nich są testy jednostkowe, w innych są testy integracyjne, w innych testy programistyczne – programista klika i jak działa to działa, a w jeszcze innych test na produkcji u klienta razem z milionami użytkowników. Generalnie każdy jakieś test ma. Wiadomo jak jest w projektach komercyjnych, klient chce aplikację działająca, wykonaną z najnowszymi i najlepszymi technikami, najlepiej napisaną przez juniorów, bez testerów i PM – tak najczęściej planowany jest budżet na aplikacje. Programiści czasem potrafią spełnić część tych wymagań i udaje się nam stworzyć aplikację, która jest stabilna (najczęściej), wygląda przyzwoicie, została napisana tak, że można ją rozwijać – generalnie klient jest zadowolony, a przynajmniej nie pieni się i jest w stanie zaakceptować produkt.

Dzieje się tak, ponieważ Ci programiści dzielnie przeklikują swoje wytwory, piszą możliwie dobry kod, przy kiepskich wymaganiach czy ich braku. Czasem gdy trzeba wyklikać to samo tysiąc razy, człowiek robi się leniwy, albo nie uważny i czy tego chcemy czy nie nie jesteśmy w stanie wyklikać wszystkich przypadków. Najczęściej gdy projekt jest już sporych rozmiarów, posiada skomplikowaną logikę lub wiele alternatywnych do siebie ścieżek.

W moim przypadku naszą słabą stroną były problemy w wydajnością. Na developerskich maszynach, gdzie testowaliśmy, mieliśmy po kilka kont użytkownika, kilka, kilkadziesiąt, lub trochę ponad setkę wpisów. Generowanie danych za każdym razem gdy baza się zmieni i trzeba było ją odtwarzać od zera nie należało do przyjemnych rzeczy, nie mieliśmy migracji, więc drop a potem create. Testy selenium pojawiły się później, ale też zajmowały wieczność.

Zmierzam do tego, że łatwo byłe tego uniknąć, generując sobie masę testowych danych. Jak tego dokonać? O tym właśnie dzisiaj, odrobina kodu się także pojawi a wszystko dostępne będzie na githubie. Jak zawsze minister zdrowia ostrzega, przykłady mogą być przejaskrawione, a rozwiązanie może się okazać przydatne tylko dla mnie.

Przykładowym problememe do rozwiązania jest prosta aplikacja, która umożliwia założenie konta, zalogowanie się, oraz dodanie jakiegoś prostego wpisu tekstowego, który jest widoczny dla wszystkich. Coś jak blog, czy czat czy lista ogłoszeń, to nie jest do końca ważne.

Zacznijmy od struktury aplikacji:

Dla prostoty wszystko co potrzebne umieściłem w jednym kontrolerze. A zwinięte foldery nie mają żadnego wpływu na treść edukacyjną tego posta.

Ok, to zaczynamy. Rejestracja nowego użytkownika wygląda tak:

   1:  [HttpGet]

   2:  public ActionResult Register()

   3:  {

   4:      var viewmodel = new RegisterViewModel();

   5:      return this.View("Register", viewmodel);

   6:  }

7:

   8:  [HttpPost]

   9:  public ActionResult Register(RegisterDto dto)

  10:  {

  11:      this.accountService.Register(dto);

  12:      return this.RedirectToAction("Index");

  13:  }

I ostatecznie prosty serwis:

   1:  public void Register(RegisterDto dto)

   2:  {

   3:      WebSecurity.CreateUserAndAccount(

   4:          dto.Email,

   5:          dto.Password);

   6:  }

Jak widać korzystam z SimpleMembershipProvider. Klasa dto do rejestracji też jest książkowo prosta:

   1:  public class RegisterDto

   2:  {

   3:      public string Email { get; set; }

   4:      public string Password { get; set; }

   5:  }

Tak więc, aby założyć konto wystarczy wpisać dwa stringi i ciach, konto dostępne. Oczywiście gdy będzie trzeba to powtórzyć wiele razy, zacznie się to robić męczące i nudne. Dlatego leniwi programiści mogą wymyślić sobie coś takiego:

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:  [HttpGet]

   2:  public ActionResult NewUsers()

   3:  {

   4:      this.testService.CreateNewUsers();

   5:      return this.RedirectToAction("Index");

   6:  }

Gdzie serwis został zaimplementowany w taki sposób:

   1:  public void CreateNewUsers()

   2:  {

   3:      var dto = new RegisterDto

   4:      {

   5:          Email = Faker.InternetFaker.Email() + Faker.NumberFaker.Number(),

   6:          Password = Faker.NumberFaker.Number(1000000000, 2000000000).ToString()

   7:      };

   8:      this.accountService.Register(dto);

   9:  }

Fakera opisałem w poprzednim poście. Warto zwrócić uwagę, że test serwis korzysta z account service. Dwie ważne rzeczy: każdy wie, że zależności powinny iść tylko w pionie, nigdy w poziomie – istnieje ryzyko zależności cyklicznych; jest to serwis testowy, wiec korzysta z normalnego przepływu danych, nie robi nic na skróty, nie oszukuje, także ułatwia nam tworzenie użytkowników, a jednocześnie testuje działające już serwisy.

Jak do tej pory jeszcze nie ma wielkiego szału, ale się powoli rozkręcam. Kolejny etap to wpis w aplikacji, kontroler wygląda tak:

   1:  [HttpGet]

   2:  [Authorize]

   3:  public ActionResult NewBlogPost()

   4:  {

   5:      var viewmodel = new BlogPostViewModel();

   6:      return this.View("NewBlogPost", viewmodel);

   7:  }

8:

   9:  [Authorize]

  10:  [HttpPost]

  11:  public ActionResult NewBlogPost(NewBlogPostDto dto)

  12:  {

  13:      this.postingService.NewBlogPost(dto);

  14:      return this.RedirectToAction("Index");

  15:  }

Kod nie powinien niczym zaskakiwać, GET i POST, oraz wymagane wcześniejsze zalogowanie się użytkownika. Warstwa implementująca:

   1:  public void NewBlogPost(NewBlogPostDto dto)

   2:  {

   3:      var userId = this.accountService.GetCurrentLoggedUserId();

   4:      var model = new BlogPost(userId, dto.Text, DateTime.Now);

   5:      this.database.BlogPosts.Add(model);

   6:      this.database.SaveChanges();

   7:  }

Dto dla nowego wpisu jest niebiańsko prosta:

   1:  public class NewBlogPostDto

   2:  {

   3:      public string Text { get; set; }

   4:  }

Ale wróćmy do serwisu, w serwisie korzystając z SMP (single membership provider) pobieramy aktualne ID użytkownika. Może nie bezpośrednio z SMP, ale prostego wrapperka nad SMP. W momencie implementacji postawiłem na opcje zaciągania danych o użytkowniku z SMP.

Sam wrapper wcześniej pokazany częściowo, teraz w calej okazałości:

   1:  class WebSecurityAccountService : IAccountService

   2:  {

   3:      public void Logout()

   4:      {

   5:          WebSecurity.Logout();

   6:      }

7:

   8:      public bool Login(LoginDto dto)

   9:      {

  10:          var result = WebSecurity.Login(dto.Email, dto.Password);

  11:          return result;

  12:      }

13:

  14:      public void Register(RegisterDto dto)

  15:      {

  16:          WebSecurity.CreateUserAndAccount(

  17:              dto.Email,

  18:              dto.Password);

  19:      }

20:

  21:      public int GetCurrentLoggedUserId()

  22:      {

  23:          return WebSecurity.CurrentUserId;

  24:      }

  25:  }

No dobra, fajny pomysł, informacje o użytkowniku zawsze pobierane z serwera, wydaje się bezpieczne i w ogóle. Ale teraz dochodzimy znowu do momentu, gdy chciałbym napisać kawałek kodu który pozwoli mi jednym kliknięciem utworzyć nowy wpis. Najlepiej za każdym razem z losowym tekstem (tutaj Faker daje radę) ale jeszcze z losowego istniejącego konta. W tym momencie na chwilę zrobiło się trudno, ale skoro mamy IAccountService i z niego pobieramy informacje o użytkowniku, czemu tego nie wykorzystać, wystarczy go tylko podmienić na inny, mój, i losować z niego użytkowników:

   1:  [HttpGet]

   2:  public ActionResult NewPosts()

   3:  {

   4:      this.testService.CreateNewPosts();

   5:      return this.RedirectToAction("Index");

   6:  }

Potem:

   1:  public void CreateNewPosts()

   2:  {

   3:      var users = this.database.Users.ToList();

   4:      var random = users.ElementAt(Faker.NumberFaker.Number(users.Count - 1));

   5:      var dto = new NewBlogPostDto

   6:      {

   7:          Text = Faker.TextFaker.Sentences(3)

   8:      };

9:

  10:      SpecialAccountService.CurrentLoggedUserId = random.Id;

11:

  12:      this.postingService.NewBlogPost(dto);

  13:  }

Docieramy powoli do mięska. Z bazy danych wyciągamy wszystko użytkowników, losujemy jednego i zapamiętujemy. Następnie linijka 10 dzięki SpecialAccountService ustawia Id “aktualnie” zalogowanego użytkownika, a następnie zwróci to Id, gdy ktoś będzie pytać o aktualnie zalogowanego użytkownika. Na końcu znowu, wykorzystujemy wcześniej napisany serwis, który zachowuje się normalnie i jest dodatkowo testowany przez nasze generowanie testowych danych. Dlaczego SpecialAccountService działa tak soczyście?

   1:  public class SpecialAccountService : IAccountService

   2:  {

   3:      private readonly WebSecurityAccountService realAccountService;

4:

   5:      public SpecialAccountService()

   6:      {

   7:          this.realAccountService = new WebSecurityAccountService();

   8:      }

9:

  10:      public void Logout()

  11:      {

  12:          this.realAccountService.Logout();

  13:      }

14:

  15:      public bool Login(LoginDto dto)

  16:      {

  17:          return this.realAccountService.Login(dto);

  18:      }

19:

  20:      public void Register(RegisterDto dto)

  21:      {

  22:          this.realAccountService.Register(dto);

  23:      }

24:

  25:      static public int CurrentLoggedUserId { get; set; }

26:

  27:      public int GetCurrentLoggedUserId()

  28:      {

  29:          return CurrentLoggedUserId;

  30:      }

  31:  }

Klasa ta implementuje IAccountService i jest ona używana w zarejestrowana w autofacu. Natomiast gdy jest potrzeba prawdziwej rejestracji użytkownika, całą robotę deleguje do prawdziwego serwisu. Dzięki temu można rejestrować,logować czy wylogować użytkownika. A bajer z aktualnym użytkownikiem ułatwia nam tworzenie losowych wpisów dla losowych użytkowników.

Wiadomo, że na produkcje nie powinno się wypuszczać takiego kodu, dlatego normalnie trzeba by przygotować odpowiednią konfigurację IOC gdzie IAccountService będzie implementowany przez WebSecurityAccountService, a na potrzeby developerki wystarczy SpecialAccountService – można tak zrobić. Można też poprosić autofaca, aby zmienił swoje dotychczasowe zachowanie i nadpisać wcześniejsze reguły:

   1:  public class HijackService : IHijackService

   2:  {

   3:      public void RestoreIOC()

   4:      {

   5:          var builder = new ContainerBuilder();

   6:          builder.RegisterType<WebSecurityAccountService>().As<IAccountService>();

   7:          builder.Update(ApplicationIocContainer.Container);

   8:      }

9:

  10:      public void HijackIOC()

  11:      {

  12:          var builder = new ContainerBuilder();

  13:          builder.RegisterType<SpecialAccountService>().As<IAccountService>().SingleInstance();

  14:          builder.Update(ApplicationIocContainer.Container);

  15:      }

16:

  17:      public IOCStatus GetStatus()

  18:      {

  19:          var isHijacked = ApplicationIocContainer.Container.Resolve<IAccountService>() is SpecialAccountService;

  20:          return isHijacked ? IOCStatus.Hijacked : IOCStatus.Normal;

  21:      }

  22:  }

Od tej pory możemy dynamicznie rejestrować swoje klasy, które ułatwią nam udawanie kogoś kim nie jesteśmy, a po skończonej generacji danych przywrócić aplikację do oryginalnego stanu i zacząć właściwe testowanie. Największą gwiazdą tego postu jest metoda Update z IOC, która umożliwia aktualizację powiązać interfejsu z klasą implementującą bez potrzeby zmiany konfiguracji, bez potrzeby restartu aplikacji, żeby autofac skonfigurował się od nowa, etc.

A dzięki temu wszystkie możemy stworzyć sobie taki prosty interfejs aplikacji:

Gdzie istnieje możliwość normalnego działa z aplikacją, ale gdy zajdzie potrzeba, można na chwilę pożyczyć kontener, wygenerować sobie niezwykle szybko sporo danych, i ponownie jednym kliknięciem przywrócić normalny stan aplikacji. Tutaj tworzę tylko jednego użytkownika i jeden wpis, ale kto bogatemu zabronić tworzyć ich tysiące?

Uwagi, pomysły chętnie przyjmę.

Kod dostępny jest na bitbucket: https://bitbucket.org/jstadnicki/jstadnicki-blog

Zaczynam od jednego, z czasem gdy będzie więcej dużych wpisów, kolejne rzeczy związane z blogiem będę wrzucane tam.

Milej niedzieli!

Generator danych Faker.net

2015/04/14 ~ Jarosław Stadnicki ~ Leave a comment

Każdy z nas jest choć trochę leniwy. Jedni troszkę mniej, inni troszkę bardziej. Ja na ten przykład czasem się rozpędzam i piszę kod, który potrzebuje. Potem o nim opowiadam, a potem ktoś pyta czemu nie skorzystałem z jakiejś tam gotowej biblioteki. Wiem, że każdy z nas należy do mensy i wie, że ten wpis nie wziął się z powietrza.
Dzisiejszy wpis dedykuje koledze Ievgenowi (blog lub @ibezuglyi)(dla ktorego specjalnie załatwiłem sobie literki, żeby wpisać jego imię do komputera), który to pokazał mi Fakera – nie palec, ale taką bibliotekę. Służy ona do generowania różnych, ale skończonych, losowych danych.
Dane podzielone są tematycznie na:

ArrayFaker
BooleanFaker
CompanyFaker
DateTimeFaker
EnumFaker
InternetFaker
LocationFaker
NameFaker
NumberFaker
PhoneFaker
StringFaker
TextFaker

W każdej znajdą się ciekawe metody, które bardzo upraszczają, ułatwiają i przyspieszają tworzenie testów, lub przynajmniej losowych wpisów.

Nowy użytkownik w naszym serwisie to taki kod: