WebMotions.Fake.Authentication.JwtBearer

 Nowy .net 8 daje nam bardzo fajną możliwość wykonywania testów integracyjnych naszych aplikacji webowych przy pomocy klasy WebApplicationFactory. Tego typu testy mogą się odbywać zarówno na faktycznej aplikacji jak i częściowo podmienionej, np. możemy sami podmienić niektóre serwisy, a inne zostawić takie jak były. Możemy zmienić bazę danych, na której mają się wykonywać testy itp. Bardzo fajne narzędzie choćby  po to, aby mieć pewność co finalnie wychodzi z naszej aplikacji. 

Czasami jednak potrzebujemy mieć aplikację z uwierzytelnieniem, tj. autoryzacją. Przykładowo przy pomocy JWT token. Oczywiście możemy pisać pełny kod od początku tak, aby łatwo się to podmieniało lub aby serwis tworzący tokena poprawnie zwracał go zarówno dla projektu z API jak i dla projektu z testami, ale czasami może się zdarzyć, że trafimy do istniejącego projektu, w którym następuje uwierzytelnienie w zewnętrznym serwisie do którego nie mamy dostępu, a przy okazji nie chcemy od samego początku przebudowywać całej aplikacji (refaktor powinien się odbywać ewolucyjnie, a nie rewolucyjnie). W takich sytuacjach z pomocą przychodzi nam paczka nugetowa: WebMotions.Fake.Authentication.JwtBearer 

Dzięki tej paczce w naszym BaseTestController możemy stworzyć metodę autoryzacji:

            dynamic data = new ExpandoObject();

            data.sub = Guid.NewGuid();

            data.role = new [] {"sub_role","admin"};

           Client.SetFakeBearerToken((object)data);

gdzie Client to jest obiekt klienta tworzony przez WebApplicationFactory w metodzie "WithWebHostBuilder(builder => {}).CreateClient();

Później możemysię to tych Claimsów odwołać w dowolnym miejscu aplikacji poprzez implementację interfejsu IHttpContextAccessor ,który możemy wstrzyknąć np. do naszej testowej implementacji ISecurityService (czy jaki tam będziemy mieli dowolny inny interfejs w naszej aplikacji odpowiedzialny za obsługę uwierzytelnienia).

Kod źródłowy dostępny na https://github.com/webmotions/fake-authentication-jwtbearer z licejcją MIT więc możemy to komercyjnie zastosować. Dzięki tej paczce, możemy sobie "zasymulować" autoryzację i podmienić jedynie serwis odpowiedzialny za autoryzację. Cała reszta aplikacji może pozostać tak jak była (sami decydujemy, którą część aplikacji chcemy testować tak jak jest, a którą chcemy symulować).

Linki

https://www.nuget.org/packages/WebMotions.Fake.Authentication.JwtBearer -  nuget

https://github.com/webmotions/fake-authentication-jwtbearer - github

https://licenses.nuget.org/MIT - licencja MIT

AML - Listy Sankcyjne

AML (Anti-Money Laundering), zwane potocznie przeciwdziałaniem praniu brudnych pieniędzy, ale... również i wspieraniu terroryzmu, są to działania, mające na celu wykrycie i odpowiednie zaraportowanie podejrzanych transakcji, a nast. ich zablokowanie, włącznie z zamrożeniem konta osob podejrzanych.

Wymogi stosowania AML w spółkach finansowych nakładają stosowne organy, takie jak np. KNF, Komisja Europejska czy Departament Skarbu USA.

Te podmioty, publikują m.in. listy os. podejrzanych. Na takich listach znajduja się znani dyktatorzy, organizacje terrorystyczne, ale ost., po aneksji Krymu również przedstawiciele Rosjiego parlamentu zaangażowani w wojnę na Ukrainie.

Te listy, zwane listami sankcyjnymi, publikowane są w różnych formatach, np. XML. W związku z powyższym, zrobiłem jednolity parser kilku list do postaci obiektowej, przy okazji udostępniając część kodów źródłowych na githubie, aby ułatwić innym walkę z terroryzmem.

Listy sankcyjne, które zostały ograne w aplikacji to:

• Consolidated list of persons, groups and entities subject to EU financial sanctions
• Specially Designated Nationals List (SDN)
• Foreign Sanctions Evaders (FSE)
• Palestinian Legislative Council (PLC) List 

Projekt postanowiłem umieścić na githubie, zarówno pod moim profilem (link), jak i pod egidą .Net Developers Poland. Jeżeli ktoś ma ochotę do rozwijania tego projektu, to zdecydowanie zapraszam.

Linki:

• Link do projektu
• Departament Skarbu 
• Strona Komisjii Europejskiej

Chocolatey , czyli.. taki windowsowy 'apt-get' ;-)

Chocolatey to jest manager pakietów, podobny do NuGet'a, ale operujący z poziomu systemu operacyjnego, czyli... taki windowsowy odpowiednik apt-get znanego z syst. Debian/Ubuntu.

Jego instalacja jest banalnie prosta, ponieważ wystarczy za pomocą wiersza poleceń uruchomić skryp powershela:

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Teraz, posiadając zainstalowane chocolatey, możemy instalować pakiety, korzystając z jego pomocy np., aplikację o nazwie 'vlc' instalujemy wpisując w linii komand:

cinst vlc

Proste i przyjemne? Jak najbardziej, szczególnie, że samo sobie pociągnie wszelkie "zależności", czyli... jeżeli będzie potrzebować dodatkowej biblioteki, to spróbuje ją pobrać (podobnie jak NuGet).

Jedyne na co trzeba uważać, to czy podczas instalacji Chcolatey skorzystało z odpowiedniej zmiennej PATH (patrz kod instalacji), ale gdyby z jakiegoś powodu ta zmienna się nie dopisała, to warto ją ustawić ręcznie.

Linki:
Fajny art. z pcworld.com jak korzytać z chocolatey
Oficjalna strona projektu
Link do githuba

edit:
Windows 10 będzie posiadał swój własny "menager pakietów" o nazwie "OneGet"

Korzystanie z kilku plików konfiguracyjnych (*.config)

Jak powszechnie wiadomo, w jednej solucji możemy mieć wiele projektów. Każdy z tych projektów może posiadać własny plik konfiguracyjny. Problem może się pojawić w sytuacji, gdy w jednej solucji chcemy korzystać z wielu plików konfiguracyjnych. Przyjrzyjmy się pewnemu realnemu scenariuszowi.

Mamy nasza przykładową aplikację konsolową, która poprawnie działa. Zaszła jednak potrzeba wykorzystania web serwisu (WCF). Zgodnie z dobrymi praktykami, do obsługi WCF tworzymy nowy, osobny projekt jako bibliotekę DLL ('class library'). Aplikacja konsolowa, posiadała już swój plik konfiguracyjny (App.config), więc próba odwołania się konfiguracji naszej biblioteki za pomocą obiektu "ConfigurationManager" spowodowała przeglądanie pliku konfiguracyjnego aplikacji. Ponieważ chcemy oddzielić konfigurację biblioteki od konfiguracji aplikacji potrzebujemy mieć oba pliki rozdzielone oraz możliwość czytania z obu plików.

Jak to należy zrobić?

Rozwiązanie można podzielić na dwa etapy. Konfiguracyjny oraz programistyczny:

W projekcie:

a) zmieniamy nazwę pliku konfiguracyjnego biblioteki, aby oba pliki konfiguracyjne miały różne nazwy

b) we właściwościach pliku konfiguracyjnego biblioteki ustawiamy właściwość "Copy to output Directory" na "Copy always"

c) w projekcie z aplikacją ustawiamy referencję na projekt z biblioteką

W kodzie biblioteki, będziemy się odwoływać do nowego pliku konfiguracyjnego w "niestandardowy" sposób. Pisząc "niestandardowy" mam na myśli w sposób inny niż za pomocą obiektu "ConfigurationManager".

W kodzie, wykorzystujemy obiekt Configuration (System.ServiceModel.Configuration) poprzez wykorzystanie jego właściwości. Przykładowa klasa, za pomocą której będziemy korzystali z nowego pliku konfiguracyjnego wygląda tak:

    public class ConfigurationManagerWrapper
    {
        private Configuration cfg;
        public ConfigurationManagerWrapper()
        {
            var path = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location);
            var fileMap = new ExeConfigurationFileMap
            {
                ExeConfigFilename = string.Concat(path, "\\mail.config")
            };
            cfg = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
        }
        public string GetSetting(string key)
        {
            AppSettingsSection section = (cfg.GetSection("appSettings") as AppSettingsSection);
            var value = section.Settings[key].Value;
            return value;
        }
        public ChannelEndpointElement GetClient(string key)
        {
            var serviceModel = ServiceModelSectionGroup.GetSectionGroup(cfg);
            var endpoints = serviceModel.Client.Endpoints;
            if (endpoints.Count > 0)
                return endpoints[0];
            return null;
        }
        public T GetSection<T>(string sectionName)
        {
            return (T)ConfigurationManager.GetSection(sectionName);
        }
    }

Bardziej zaawansowany przykład wykorzystania takiego pliku .config można zobaczyć w przeznaczonym do tego projekcie na github mojego autorstwa stworzonym w celu demonstracji kodu.

Pomocne linki:
stackoverflow.com - how-do-i-retrieve-appsettings-from-the-assembly-config-file
weblogs.asp.net - cibrax - getting-wcf-bindings-and-behaviors-from-any-config-source.aspx

Git

Czym jest Git, mam nadzieję, że każdy szanujący się programista doskonale wie, a pozostałym przypomnę, że jest to rozproszony system kontroli wersji. Git powszechnie uważany jest, za najlepszy, dostępny na rynku system kontroli wersji. Porównanie Git-a z TFS, jakiś czas temu napisał mój ulubiony bloger .NET, czyli Maciej Aniserowicz -> 'w-czym-git-jest-lepszy-od-tfs'

Pomijając już wszelkie 'ohy i ahy' Maćka, które wygłasza za każdym razem, gdy tylko ktoś pozwoli mu się odezwać, Git ma kilka zalet, które na chwilę obecną bardzo mi się podobają:
- możliwość pracy off-line -> niestety w przeszłości, zdarzyła nam się syt., w której padł nam dysk na serwerze, na którym mieliśmy nasz serwer SVN. Dysk, a dokładniej dane dało się w końcu odzyskać, jednak te kilka dni programowania bez kontroli wersji do najprzyjemniejszych, a przynajmniej do najbardziej komfortowych nie należały. Wrzucając kod na git-a, można pracować 'off-line', a po podłączeniu się 'on-line' mamy pewność, że serwery będą działały tak jak należy i nie musimy się martwić o "spalenie się dysku"
- możliwość umieszczenia mojego kodu źródłowego w bardziej przyjaznej programiście formie, niż wklejanie go tutaj, co delikatnie mówiąc było lekko "wieśniackie".

Jako hosting, na pierwszy ogień poszedł GitHub ponieważ dla publicznych repozytoriów, jest darmowy link. Owszem, Github nie jest monopolistą i  istnieje konkurencja w postaci Bitbucket, który w dodatku pozwala na kilka prywatnych repozytoriów, ale od czegoś trzeba zacząć. Zawsze najpierw trzeba zrobić ten pierwszy krok.

Możliwe, że kiedyś się przeniosę na Bitbucket, albo inne podobne rozwiązanie, ale puki co, zapraszam na moje konto na github, gdzie w miarę możliwości będę się starał wrzucać moje programistyczne wypociny.