Opublikowane w

Auth0 – Aplikacja do odpalania rakiet – backend

Rejestracja backendu

Zarejestrowanie backendu jako API w Auth0 wymaga wcześniejszej rejestracji tenanta. Jeżeli tego jeszcze nie zrobiłeś przejdź do artykułu o delegowaniu zarządzania tożsamością aby dowiedzieć się jak to zrobić.

Wartość pola wystawca (authority) można znaleźć klikając w opcję Applications w menu po lewej stronie panelu tenanta.

Na ekranie, który ona otwiera, znajduje się aplikacja o nazwie Auth0, należy ją otworzyć wartość pola Authority znajduje się w polu domain.

Aby uzyskać wartość pola audience należy zarejestrować API, a żeby to zrobić należy z ww menu wybrać opcję „APIs”.

Na wyświetlonej liście znajduje się już jedno API nie należy go usuwać, natomiast nad listą jest wyświetlony przycisk „Create API”. W wyświetlonym formularzu należy wprowadzić nazwę, która nie ma większego znaczenia, oraz identyfikator – który będzie używany przez serwis jako audience. Ja wprowadziłem wartość http://rocket-service.com

Na koniec wystarczy kliknąć przycisk Create i gotowe.

Oprócz API Auth0 generuje także wpis w sekcji „Applications”, jest to testowa aplikacja pozwalająca pobrać token autoryzacyjny bez podawania loginu i hasła. Wymaga za to podania id  i specjalnego tokenu, proponuję usunąć tą aplikację.

Na tym etapie backend jest ukończony, jego kod jest dostępny na githubie.

Strony: 1 2 3
Opublikowane w

Auth-0 aplikacja do odpalania rakiet – frontend

Obsługa ścieżek

Do obsługi ścieżek w aplikacji dodałem pakiet aurelia router 

export class Home { }

Następnie usunąłem ciało klasy App w pliku app.ts i dodałem metodę configureRouter 

public configureRouter(config: RouterConfiguration, router: Router): void {
 	this.router = router;

	config.title = 'Rocket Launcher';
	config.options.pushState = true;
	config.map([
		{route: ['', 'home'],     name: 'home',           moduleId: PLATFORM.moduleName('home')},
		{route: 'launch-console', name: 'launch-console', moduleId: PLATFORM.moduleName('launch-console')},
		{route: 'logged-in',      name: 'logged-in',      moduleId: PLATFORM.moduleName('logged-in')},
		{route: 'logged-out',     name: 'logged-out',     moduleId: PLATFORM.moduleName('logged-out')}
	]);
}
  • config.title – ustawia tytuł aplikacji
  • config.options.pushState = true – zmienia działanie routingu, domyślnie aurelia interpretuje część adresu po płotku(#) po włączeniu tej opcji interpretowana jest część przed płotkiem, jest to konieczne ponieważ auth0 po płotku przekazuje dane wymagane do autoryzacji
  • config.map – służy do konfigurowania ścieżek

Natomiast treść pliku app.html zmieniłem na:

Element router-view wyświetla aktywną stronę.

Strony: 1 2 3 4 5 6
Opublikowane w

Auth0 – Delegowanie zarządzania tożsamością

Kiedy delegować autoryzację?

Czytając dokumentację techniczną Auth0 oraz przygotowując aplikacje wykorzystujące tego dostawcę, da się dostrzec scenariusze, w których delegowanie zarządzania kontami użytkowników jest jednoznacznie dobrą decyzją.

Dostawca oferuje (prawie)dokładnie to czego potrzebujemy

Większość dostawców tożsamości zaadresowało bardzo szeroki zakres wymagań. Konfiguracja dostawcy zajmuje znacznie mniej czasu niż pisanie autorskiego rozwiązania. Co może być szczególnie ważne w początkowej fazie projektu, gdzie każda godzina opóźnienia w budowie, może decydować o tym czy okaże się on sukcesem czy porażką.

Nie znamy wymagań

Innym problemem występującym na wczesnym etapie tworzenia projektu jest sytuacja, w której często nie znamy wymagań dotyczących autentykacji np. zakresu gromadzonych danych użytkownika. Tworzenie własnego rozwiązania, które następnie zostanie przepisane jest marnotrawstwem zasobów, a podpięcie zewnętrznego dostawcy w domyślnej konfiguracji jest ekstremalnie szybkie.

Należy też dodać że większość pracy wymaganej do integracji z zewnętrznym dostawcą tożsamości nie różni się od integracji z autorskim rozwiązaniem. W optymistycznym przypadku migracja do innego dostawcy, albo autorskiego rozwiązania polega na zmianach w pliku konfiguracyjnym.

Niektórzy twierdzą, że na bardzo wczesnym etapie można wcale nie zabezpieczać serwisu. Podpięcie autentykacji w późniejszym etapie powoduje powstanie błędów regresji – wiele modułów przestaje działać. Istnieje też ryzyko pominięcia zabezpieczenia całych modułów, lub ich części.

Relatywnie wysokie koszty utrzymania autoryzacji

Idealne oprogramowanie robi to co robić powinno i nie wymaga zmian. Posiadanie własnego mechanizmu autoryzacji może wymusić wprowadzenie zmian w aplikacji, a te zmiany pociągają za sobą inne koszty, takie jak przeprowadzenie testów regresji czy wdrożenia.

W takim wypadku wykorzystanie zewnętrznego dostawcy może być tańsze.

Czego nie należy się bać?

Oczywiście sytuacja nie zawsze jest różowa, są sytuacje, w których integracja wiąże się dodatkowymi kosztami, może być jednak ciągle opłacalna.

Niestandardowa rejestracja użytkownika

Większość dostawców dostarcza pustej bazy użytkowników i umożliwiają rejestrację w systemie dowolnej osobie. Są to jednak tylko ustawienia domyślne, rejestrację można wyłączyć jednym kliknięciem. Można też napisać własne ekrany logowania/rejestracji, robiąc to tracimy jednak jeden z powodów dla których decydujemy się na delegowanie.

Integracja z serwisami społecznościowymi

Jedyne czego, w celu integracji z facebookiem, wymaga wielu dostawców to kliknięcie w jeden przełącznik i uzupełnienie formularza. Niestety formularz zawiera kilka pól, których wypełnienie wymaga przebicia się przez biurokrację tej firmy. Przez biurokrację trzeba przejść także przy pisaniu własnego mechanizmu, jej udział sprawia jednak, że zysk wynikający z delegacją jest mniejszy.

Inne portale społecznościowe także wymagają przejścia przez biurokrację, zajmuje to jednak mniej czasu.

Import kont użytkowników

Istnieją dostawcy którzy oferują możliwość importu danych użytkowników. Może to się jednak wiązać z pewnymi niedogodnościami dla użytkownika. Auth0 nie umożliwia importu haseł, więc nawet jeżeli jakimś cudem je posiadamy to dostawca je zignoruje, a użytkownik i tak będzie musiał ustawić hasło przy kolejnym logowaniu.

Vendor locking

Napisałem wcześniej, że w optymistycznym przypadku zmiana dostawcy wymusza tylko aktualizację konfiguracji aplikacji. Problem w tym, że optymistyczne przypadki zdarzają się rzadko. Dostawcy dostarczają własnych bibliotek ułatwiających integrację, jednak ich użycie sprawia, że przesiadka jest trudniejsza.

Jeżeli mamy użytkowników, którzy na swoich maszynach, czy to typu dektop, czy to smartfonach, uporczywie używają starej wersji oprogramowania, migracja może oznaczać ich utratę.

Rozstanie jest trudne, jednak nie niemożliwe. Potwierdza to historia zespołu, który zbudował własnego dostawcę autoryzacji gdy dostawca nie dawał rady obsłużyć ruchu przez nich generowanego. Oznacza to, że pomimo tak długiej relacji, byli w stanie zakończyć ten związek.

Przekierowania na inną domenę

Domyślnie dostawcy tożsamości wymagają przekierowania na stronę w ich domenie albo użycia elementu iframe. Takie zachowanie aplikacji budzi podejrzenia szczególnie ostrożnych użytkowników, ponieważ z podobnych metod korzystają hackerzy w atakach typu phishing. Zachowanie to da się nadpisać ale wymaga to dodatkowej pracy.

Kiedy nie delegować?

Wymagania prawne

Jeżeli prawo, albo regulacje w organizacji, zabraniają przetrzymywania danych użytkowników po za własnymi serwerami, użycie zewnętrznego dostawcy jest niemożliwe albo znacznie utrudnione.

Koszta

Większość dostawców tożsamości działa w modelu SaaS co oznacza że miesięczna opłata zależy od ilości użytkowników i zakresu funkcjonalności. W szczególnych przypadkach, takich jak ekstremalnie duża ilość użytkowników, może się okazać, że napisanie własnego rozwiązania i utrzymywanie kont we własnym data-center będzie znacznie tańsze.

Niestandardowe mechanizmy autoryzacji

Istnieją rozwiązania techniczne utrudniające integrację z zewnętrznym dostawcą:

  • komunikacja z oprogramowaniem działającym w  intranecie, np. usługą katalogową (Active Directory/Open LDAP), jest utrudniona, administrator sieci powie Ci czy jest możliwa.
  • autoryzacja z wykorzystaniem programów klienckich – najpopularniejsze rozwiązanie do obsługi podpisów cyfrowych w Polsce wymaga uruchomienia apletu Javy, integracja z tą technologią, nawet bez uwzględnienia zewnętrznego dostawcy tożsamości, jest trudna. 

Czy delegować?

Przez wiele lat każdy własny projekt zaczynałem od napisania mechanizmu autoryzacji, a wiele z nich skończyło się na tym etapie. Wygląda na to, że kolejne będę zaczynał od integracji z dostawcą wykorzystując najtańszy możliwy plan i przechodził czym prędzej do rozwiązywania problemów biznesowych.

Strony: 1 2
Opublikowane w

Recenzja Noblechairs HERO Gaming skórzany

Wrażenia z użytkowania

Krzesło jest wygodne, przyjemne w dotyku i wygląda naprawdę dobrze. Jak już wcześniej wspomniałem krzesło jest przystosowane dla osób do 150 kg, ważąc połowę tej masy nie czuję się w nim dobrze, musiałem jednak obniżyć siedzisko prawie do samego dołu, zmniejszyć rozstaw podłokietników i przekręcić to pokrętło pod siedziskiem służące do regulacji oporu „bujania się”.

Pokoik, służący mi za biuro, uniemożliwia pobawienie się wychyleniem oparcia i bujaniem się, myślę że spokojnie można w nim spać.

Co do wad to w wersji z prawdziwej skóry podłokietniki pokryte są skórą ekologiczną. Jest ona wysokiej jakości, mimo wszystko jest to eko-skóra.

Oglądając inne recenzje tego spotkałem się z opiniami, że regulacja lędźwi sprawia, że poduszka pod lędźwia jest zbędna, nie zgadzam się z tą opinią. Będąc szczęśliwym posiadaczem prawie pełnoletniego Audi A6 przywykłem do regulacji z tego samochodu, która jest dość agresywna, w tym fotelu jest ledwo wyczuwalna, a poduszeczka często wędruje gdzie jej miejsce.

Podsumowując: jestem naprawdę zadowolony z zakupu i zostanie on ze mną na dłużej. Gdybym jednak miał wybierać ponownie wybrałbym model noblechairs ICON, który nie ma regulacji lędźwi, a w wersji skórzanej kosztuje 450 zł mniej.

Linki do sklepu:

Strony: 1 2 3
Opublikowane w

Relacja z Dotnetos – .Net performance world

Piątego listopada 2018 w Hotelu „Airport Hotel Okęcie” w Warszawie odbyła się konferencja Dotnetos – .Net performance world do udziału w niej skłoniły mnie dwa czynniki: fakt że są prelegenci prze-kozakami .Net, oraz to że w tym roku nie uczestniczyłem jeszcze w żadnej innej konferencji. 

<TLDR>

Dużo technicznego mięsna na najwyższym poziomie, w dodatku w bardzo przystępnej cenie. Zdecydowanie polecam wszystkim osobom będącym na pozycjach od mid .Net developer do architekta. Osoby z mniejszym doświadczeniem oraz niezwiązane z technologią .Net mogą się czuć lekko zagubione. W organizacji samej konferencji można jednak trochę poprawić.

</TLDR>

Czytaj dalej Relacja z Dotnetos – .Net performance world
Opublikowane w

Nasza droga do Reactive Extensions – cz. 2 – Event Aggregator na ratunek

W poprzednim wpisie opisałem problem z wyborem architektury aplikacji przed jakim stanął nasz zespół. W drugiej części opiszę jakie problemy udało się rozwiązać dzięki wzorcowi event aggregator, jakie pozostały nie rozwiązane, a jakie powstały w wyniku jego użycia.

Czytaj dalej Nasza droga do Reactive Extensions – cz. 2 – Event Aggregator na ratunek
Opublikowane w

Nasza droga do Reactive Extensions – cz. 1 – Wstęp

Artykuł w wersji anglojęzycznej jest dostępny na blogu firmy Grape Up

Jeden z produktów jakie ostatnio rozwijaliśmy w naszym zespole, jest aplikacją desktopową opartą o rozbudowaną bibliotekę, która dostarczała spójne API do komunikacji, opartej o różne protokoły związane z telekomunikacją, co sprawiało że generowała naprawdę dużo sygnałów.

Czytaj dalej Nasza droga do Reactive Extensions – cz. 1 – Wstęp
Opublikowane w

Cloud Foundry – notatki – Wstęp

Rozpocząłem właśnie naukę nowej technologii – Cloud Foundry (CF). Aby przybliżyć czym jest CF umieszczam tutaj trochę marketingowego bełkotu. Możesz go pominąć klikając w link.

CF obiecuje, że aplikacje tworzone pod jej kątem mogą być wdrożone i uruchomione na chmurach różnych dostawców, zarówno tych publicznych takich jak: AWS, Azure czy Google Cloud, jak i na rozwiązaniach typu private cloud np. OpenStack czy nawet maszyna wirtualna virtual-box.

Czytaj dalej Cloud Foundry – notatki – Wstęp