Skip to content

Architektura

Jump to bottom
stepanekp edited this page Jan 20, 2024 · 9 revisions

Rozdělení aplikace ve v2

  • V rámci v1 (verze 1) SPADe je aplikace de facto monolitem. Tedy není zde oddělen backend od frontendu "tlustou" čarou.
  • Překlápění aplikace do v2 (verze 2) rozdělilo frontend od backendu na dvě nezávislé aplikace. Spring aplikace je tedy množina RESTful API (controllery, services), která posílá data ve formátu JSON klientské aplikaci (React JS), která je následně vykreslí.
  • Kromě toho byla ve v2 přidána třetí aplikace Authenticator (Spring), která zajišťuje autentikaci.
  • Nová mikroservisní arichtektura ve verzi v2 vypadá takto:

  • Odkazy na repozitáře nově vytvořených aplikacích se nachází zde

Spring Boot

  • Aplikace využívá klasické programátorské konvence technologie Spring Boot a REST API.

Spring REST Controller

  • Controller řídí logiku toku informací aplikace s MVC architekturou, tedy řídí, jak uživatel s aplikací komunikuje. Rozhoduje, jaký response odeslat na konkrétní uživatelský request.
  • Spring aplikace v kontextu SPADe v2 je pouze RESTové API, všechny controllery jsou tedy anotovány pomocí @RestController. Tato anotace implikuje, že třída je REST controller (správná konvence).

Spring Boot dokumentace

HTTP návratové hodnoty

v2/user/register

  • 201 pro úspěšné zaregistrování
  • 400 pro informování o existenci uživatele se stejným jménem.
  • 400 pro informování o nevalidních hodnotách, které uživatel zadal do registračního formuláře.
    • Formulář je ošetřen nejen na úrovni serveru, ale i na úrovni klienta pomocí JS validační metodiky, nicméně to není neprůstřelné a pokud to náhodou projde až na server, uživatel to pěkně schytá :)
  • 500 pro generickou chybu.
  • 503 pro informování o jiné generické chybě.
    • 500 i 503 budou nadále rozpadlé na menší podchyby v průběhu dalších iterací

v2/user/login

  • 200 pro úspěšné přihlášení. V takovém případě je zaslán uživateli i JWT token vygenerován autentizační aplikací
  • 401 pro neúspěšné přihlášení. Uživatel je informován, že nemohl být přihlášen.

v2/user/logout

  • 200 pro úspěšné odhlášení. Uživatel v takovém případě
  • chybové err kódy budou ještě dodefinovány

Komunikace s autentizační aplikací

  • Všechny konkrétní implementace spravující komunikaci (filtrování requestů a autentizaci) jsou umístěny v package v2/security
  • Ve SPADe aplikaci byla implementována (dle patřičných návodů) speciální konfigurační třída, u které se pomocí anotace zapnula autentikace veškerých requestů přicházejících na SPADe aplikace z webové aplikace SPAWn.
  • První kritický bod: implementována třída WebSecurityConfig, která dědí od Spring Boot třídy WebSecurityConfigurerAdapter, jenž nutí implementaci config metody, ve které se zapíná základní nastavení autentizačních praktik.
  • Druhý kritický bod: Při definování config metody z předchozího bodu bylo nutné vytvořit třídu, která dělá samotný "router" z předchozího nakonfigurování adapteru. Tato třída dělající samotný router se jmenuje JwtAuthenticationFilter.java a dědí od třídy OncePerRequest, což má za úkol zajistit idempotentnost, jinými slovy: pokud by se stalo, že by více vláken zaslalo jeden a ten samý request ze strany SPAWn, tak se vykoná pouze jednou. Zde je implementována metoda doInternalFilter, ve kterém odchytáváme všechny requesty. U těchto requestů kontrolujeme autentizaci (zda na to má uživatel právo) zasláním requestu s JWT tokenem extrahovaným z hlavičky od uživatele na autentikační aplikaci. Více informací je v další kapitole u Autentikační aplikace.
  • SPADe pro kontrolování autentizace zasílá s každým (autentizovaným) requestem žádost na REST API endpoind auth aplikace localhost:/authenticate s přiloženým JWT tokenem.

Clone this wiki locally