Alapvető, UAA által védett JHipster Microservice kiépítése

1. Áttekintés

Korábbi cikkekben a JHipster alapjairól és annak mikroszolgáltatás-alapú alkalmazás előállításának módjáról volt szó.

Ebben az oktatóanyagban felfedezzük a JHipster felhasználói fiókját és engedélyezési szolgáltatását - röviden UAA - és hogyan kell használni egy teljes értékű JHispter-alapú mikroszolgáltatás alkalmazás biztosításához. Még jobb, hogy mindez elérhető egyetlen kódsor megírása nélkül!

2. Az UAA alapvető jellemzői

Az előző cikkekben épített alkalmazások fontos jellemzője, hogy a felhasználói fiókok szerves részét képezték ezeknek. Ez rendben van, ha egyetlen alkalmazásunk van, de mi van, ha meg akarjuk osztani a felhasználói fiókokat több JHipster által generált alkalmazás között? Itt jön be a JHipster UAA.

A JHipster UAA egy mikroszolgáltatás az alkalmazásunk egyéb szolgáltatásaitól függetlenül építjük, telepítjük és futtatjuk. Ez szolgál:

  • OAuth2-hitelesítő kiszolgáló, a Spring Boot megvalósításán alapul
  • Identity Management Server, amely egy felhasználói fiók CRUD API-t tesz ki

A JHipster UAA olyan tipikus bejelentkezési funkciókat is támogat, mint az önregisztráció és az „emlékezzen rám”. És természetesen teljes mértékben integrálódik a többi JHipster szolgáltatással.

3. Fejlesztői környezet beállítása

A fejlesztés megkezdése előtt először meg kell győződnünk arról, hogy környezetünk minden előfeltételét fel van-e állítva. Az Intro To JHipster cikkünkben leírt összes eszköz mellett szükségünk lesz egy működő JHipster Registry-re. Gyors összefoglalásként a rendszerleíró adatbázis szolgáltatás lehetővé teszi, hogy az általunk létrehozott különböző szolgáltatások megtalálják és beszéljenek egymással.

A rendszerleíró adatbázis létrehozásának és futtatásának teljes eljárását a JHipster with a Microservice Architecture cikkünk 4.1 szakasza ismerteti, ezért itt nem ismételjük meg. Docker kép is elérhető, és alternatívaként is használható.

4. Új JHipster UAA szolgáltatás létrehozása

Generáljuk az UAA szolgáltatásunkat a JHipster parancssori segédprogram segítségével:

$ mkdir uaa $ cd uaa $ jhipster 

Az első kérdésre válaszolnunk kell, hogy melyik típusú alkalmazást szeretnénk létrehozni. A nyílbillentyűkkel kiválasztjuk a „JHipster UAA (a microservice OAuth2 hitelesítéshez)” lehetőséget:

Ezután néhány kérdést fogunk kérni a létrehozott szolgáltatással kapcsolatos konkrét részletekről, például az alkalmazás nevéről, a kiszolgáló portjáról és a szolgáltatás felfedezéséről:

Az alapértelmezett válaszok többnyire rendben vannak. Ami az alkalmazás alapnevét illeti, ami a keletkezett műtárgyak sokaságát érinti, úgy döntöttünk „Uaa” (kisbetű) - értelmes név. Ha akarjuk, játszhatunk a többi értékkel, de ez nem változtatja meg a létrehozott projekt főbb jellemzőit.

Miután megválaszolta ezeket a kérdéseket, a JHipster létrehozza az összes projektfájlt és telepíti npm csomagfüggőségek (amelyeket ebben az esetben nem igazán használnak).

Most már használhatjuk a helyi Maven szkriptet az UAA szolgáltatásunk felépítéséhez és futtatásához:

$ ./mvnw ... kihagyott üzenetek 2018-10-14 14: 07: 17.995 INFO 18052 --- [restartedMain] com.baeldung.jhipster.uaa.UaaApp: ------------ ---------------------------------------------- "uaa" alkalmazás fut! Hozzáférési URL-ek: Helyi: // localhost: 9999 / Külső: //192.168.99.1:9999/ Profil (ok): [dev, swagger] ------------------- --------------------------------------- 2018-10-14 14: 07: 18.000 INFO 18052 --- [restartedMain] com.baeldung.jhipster.uaa.UaaApp: --------------------------------- ------------------------- Config Server: Csatlakoztatva a JHipster Registry konfigurációs kiszolgálóhoz! -------------------------------------------------- -------- 

A legfontosabb üzenet, amelyre oda kell figyelni, az az, hogy az UAA csatlakozik a JHipster Registry-hez. Ez az üzenet azt jelzi, hogy az UAA képes volt regisztrálni magát, és elérhetővé válik majd más mikroszolgáltatások és átjárók számára.

5. Az UAA szolgáltatás tesztelése

Mivel a létrehozott UAA szolgáltatásnak önmagában nincs felhasználói felülete, közvetlen API-hívásokat kell használnunk annak tesztelésére, hogy a várakozásoknak megfelelően működik-e.

Két funkcióval kell megbizonyosodnunk arról, hogy működnek-e, mielőtt más alkatrészekkel vagy rendszerünkkel használnánk: OAuth2-tokenek létrehozása és fiókkeresés.

Először nézzük szerezzen be egy új tokent az UAA OAuth végpontjából, egy egyszerű használatával becsavar parancs:

$ curl -X POST --data \ "felhasználónév = felhasználó & jelszó = felhasználó & grant_type = jelszó & hatókör = openid" \ // web_app: [e-mail védett]: 9999 / oauth / token 

Itt használtuk a jelszó megadása folyamatot, két pár hitelesítő adat felhasználásával. Ebben a folyamatban kliens hitelesítő adatokat küldünk alap HTTP hitelesítéssel, amelyet közvetlenül az URL-be kódolunk.

A végfelhasználói hitelesítő adatokat a törzs részeként küldjük el, a szokásos felhasználónév és jelszó paraméterek felhasználásával. A megnevezett felhasználói fiókot is használjuk „Felhasználó”, amely alapértelmezés szerint elérhető a tesztprofilban.

Feltéve, hogy minden részletet helyesen adtunk meg, kapunk egy választ, amely hozzáférési tokent és frissítési tokent tartalmaz:

{"access_token": "eyJh ... (token kihagyva)", "token_type": "hordozó", "refresh_token": "eyJ ... (token kihagyva)", "expires_in": 299, "hatókör": " openid "," iat ": 1539650162," jti ":" 8066ab12-6e5e-4330-82d5-f51df16cd70f "}

Most már tehetünk használja a visszaküldöttet access_token hogy információkat kapjon a társított fiókról a számla forrás, amely elérhető az UAA szolgáltatásban:

$ curl -H "Engedélyezés: Bemutató eyJh ... (a hozzáférési token elhagyva)" \ // localhost: 9999 / api / account {"id": 4, "login": "user", "firstName": "User" , "vezetékNév": "Felhasználó", "e-mail": "[e-mail védett]", "imageUrl": "", "aktivált": igaz, "langKey": "en", "createdBy": "rendszer", " createdDate ":" 2018-10-14T17: 07: 01.336Z "," lastModifiedBy ":" rendszer "," lastModifiedDate ": null," hatóságok ": [" ROLE_USER "]} 

Kérjük, vegye figyelembe, hogy ezt a parancsot ki kell adnunk, mielőtt a hozzáférési token lejárna. Alapértelmezés szerint az UAA szolgáltatás öt percig érvényes tokent ad ki, ami ésszerű érték a termelés számára.

A szerkesztésével könnyen megváltoztathatjuk az érvényes tokenek élettartamát alkalmazás-.yml fájl, amely megfelel annak a profilnak, amely alatt az alkalmazást futtatjuk, és a uaa.web-client-configuration.access-token-érvényesség-másodperc alatt kulcs. A beállítási fájlok a src / main / resources / config UAA projektünk könyvtárát.

6. Az UAA-kompatibilis átjáró létrehozása

Most, hogy biztosak vagyunk benne, hogy az UAA szolgáltatásaink és szolgáltatásnyilvántartásaink működnek, hozzunk létre egy ökoszisztémát, amellyel ezek kölcsönhatásba léphetnek. A végére hozzáadjuk:

  • Szög alapú kezelőfelület
  • Mikroszolgáltatás háttér
  • API-átjáró, amely mindkettőt előtérbe helyezi

Kezdjük valójában az átjáróval, mivel ez lesz a szolgáltatás, amely tárgyalni fog az UAA-val a hitelesítésről. Fogja az elülső alkalmazásunkat, és továbbítja az API kéréseket más mikroszolgáltatások felé.

Ismét a JHipster parancssori eszközt fogjuk használni egy újonnan létrehozott könyvtárban:

$ mkdir gateway $ cd gateway $ jhipster

Mint korábban, néhány kérdésre is választ kell adnunk a projekt létrehozása érdekében. A legfontosabbak a következők:

  • Alkalmazás típusa: „Microservices gateway” kell legyen
  • Alkalmazás neve: Ezúttal az „átjárót” fogjuk használni
  • Szolgáltatás felfedezése: Válassza a „JHipster registry” lehetőséget
  • Hitelesítés típusa:Ki kell választanunk a „Hitelesítés JHipster UAA szerverrel” opciót itt
  • UI keretrendszer: Válasszuk az „Angular 6” -t

Miután a JHipster elkészítette az összes műtárgyat, elkészíthetjük és futtathatjuk az átjárót a mellékelt Maven wrapper szkript segítségével:

$ ./mwnw ... sok üzenet kihagyva ---------------------------------------- ------------------ Az 'átjáró' alkalmazás fut! Hozzáférési URL-ek: Helyi: // localhost: 8080 / Külső: //192.168.99.1:8080/ Profil (ok): [dev, swagger] ------------------- --------------------------------------- 2018-10-15 23: 46: 43.011 INFO 21668 --- [restartedMain] c.baeldung.jhipster.gateway.GatewayApp: --------------------------------- ------------------------- Config Server: Csatlakoztatva a JHipster Registry konfigurációs kiszolgálóhoz! -------------------------------------------------- -------- 

A fenti üzenettel úgy érhetjük el alkalmazásunkat, hogy a böngészőnkre mutatunk // localhost: 8080, amelynek meg kell jelenítenie az alapértelmezetten létrehozott kezdőlapot:

Menjünk tovább, és lépjünk be az alkalmazásunkba a Fiók> Bejelentkezés menü tétel. Majd használjuk admin / admin hitelesítő adatokként, amelyeket a JHipster alapértelmezés szerint automatikusan létrehoz. Minden jól megy, az üdvözlő oldalon megjelenik egy üzenet, amely megerősíti a sikeres bejelentkezést:

Összefoglalva azt, ami történt, hogy idekerültünk: Először az átjáró elküldte a hitelesítő adatainkat az UAA OAuth2 token végpontjának, amely azokat validálta, és egy hozzáférést és egy frissítő JWT tokent tartalmazó választ generált. Az átjáró ekkor elvette ezeket a tokeneket, és cookie-ként visszaküldte a böngészőbe.

Ezután a szögletes előtér a / uaa / api / account API, amely ismét átjárót továbbított az UAA-hoz. Ebben a folyamatban az átjáró elviszi a hozzáférési jogkivonatot tartalmazó cookie-t, és annak értékét felhasználva engedélyezési fejlécet ad a kéréshez.

Ha szükséges, mind az UAA, mind a Gateway naplóinak ellenőrzésével nagyon részletesen láthatjuk ezt az áramlást. A teljes beállítással a vezetékes szintű adatokhoz is hozzájuthatunk org.apache.http.wire naplózó szint DEBUG.

7. UAA-kompatibilis mikroszolgáltatás előállítása

Most, hogy az alkalmazási környezetünk beindult, itt az ideje, hogy hozzáadjunk egy egyszerű mikroszolgáltatást. Létrehozunk egy „árajánlatok” mikroszolgáltatást, amely egy teljes REST API-t tesz elérhetővé, amely lehetővé teszi számunkra, hogy készítsünk, lekérdezzünk, módosítsunk és töröljünk részvényárfolyamokat. Minden ajánlatnak csak három tulajdonsága lesz:

  • Az idézet kereskedelmi szimbóluma
  • Az ára, és
  • Az utolsó kereskedés időbélyege

Térjünk vissza a terminálunkra, és a JHipster parancssori eszközével hozzuk létre projektünket:

$ mkdir $ cd idézi $ jhipstert 

Ezúttal arra kérjük a JHipstert, hogy hozzon létre egy Mikroszolgáltatás alkalmazás, amelyeket „idézeteknek” hívunk. A kérdések hasonlóak azokhoz, amelyekre korábban válaszoltunk. Az alapértelmezéseket a legtöbbjüknél megtarthatjuk, kivéve ezt a hármat:

  • Szolgáltatás felfedezése: Válassza a „JHipster Registry” lehetőséget, mivel már használjuk az architektúránkban
  • Az UAA alkalmazás elérési útja: Mivel az összes projektkönyvtárat egy mappában tartjuk, ez így lesz ../uaa (hacsak nem változtattunk rajta, természetesen)
  • Hitelesítés típusa: Válassza a „JHipster UAA szerver” lehetőséget

Így néz ki egy tipikus válaszsor esetünkben:

Amint a JHipster befejezte a projekt létrehozását, folytathatjuk és felépíthetjük:

$ mvnw ... sok-sok üzenet kihagyva ---------------------------------------- ------------------ Az "idézetek" alkalmazás fut! Hozzáférési URL-ek: Local: // localhost: 8081 / External: //192.168.99.1:8081/ Profil (ok): [dev, swagger] ------------------- --------------------------------------- 2018-10-19 00: 16: 05.581 INFO 16092 --- [restartedMain] com.baeldung.jhipster.quotes.QuotesApp: --------------------------------- ------------------------- Config Server: Csatlakoztatva a JHipster Registry konfigurációs kiszolgálóhoz! -------------------------------------------------- -------- ... további üzenetek kihagyva 

A „Csatlakozás a JHipster Registry konfigurációs kiszolgálóhoz!” Üzenet az, amit itt keresünk. Jelenléte arról árulkodik, hogy a mikroszolgáltatás regisztrálta magát a rendszerleíró adatbázisba, és emiatt az átjáró képes lesz továbbítani a kéréseket az „idézetek” erőforrásunkhoz, és egy szép felhasználói felületen megjeleníteni, amint létrehoztuk. Mivel mikroszolgáltatási architektúrát használunk, ezt a feladatot két részre osztottuk:

  • Hozza létre az „idézetek” erőforrás háttérszolgáltatást
  • Hozzon létre egy „idézőjelű” felhasználói felületet a kezelőfelületen (az átjáró projekt része)

7.1. Az Idézetek erőforrás hozzáadása

Először is meg kell győződjön meg arról, hogy az idézőjelű mikroszolgáltatás alkalmazás le van állítva - ugyanazon a konzol ablakon találhatjuk meg a CTRL-C-t, amellyel korábban futtattuk.

Nézzük vegyen fel egy entitást a projektbe a JHipster eszközével. Ezúttal a import-jdl parancsot, amely megment minket az unalmas és hibára hajlamos folyamattól, amikor minden részletet külön adunk meg. A JDL formátumról további információt a teljes JDL referenciában talál.

Ezután mi nevű szöveges fájlt hozhat létre idézetek.jh a mi Idézet entitás meghatározása, néhány kódgenerálási irányelvvel együtt:

entitás Idézet {szimbólum Karaktersorozat szükséges egyedi, ár BigDecimal szükséges, lastTrade ZonedDateTime szükséges} dto Idézet mapstruct oldalszámmal Idézet lapozási szolgáltatással Idézet serviceImpl microservice Idézet idézetek szűrővel Idézet clientRootFolder Idézet idézetekkel 

Most már tehetünk importálja ezt az entitás definíciót projektünkhöz:

$ jhipster import-jdl idézetek.jh 

Megjegyzés: az importálás során a JHipster konfliktusra panaszkodik, miközben módosításokat hajt végre a master.xml fájl. Nyugodtan választhatjuk a átír opció ebben az esetben.

Mostantól újra felépíthetjük és futtathatjuk a mikroszolgáltatásunkat mvnw. Amint elkészült, ellenőrizhetjük, hogy az átjáró felveszi-e az új útvonalat, amelyhez hozzáfér Gateway nézet, elérhető a Adminisztráció menü. Ezúttal láthatjuk, hogy van bejegyzés a "/idézetek/**" útvonal, amelyazt mutatja, hogy a háttérprogram készen áll a felhasználói felület használatára.

7.2. Az Idézetek felhasználói felület hozzáadása

Végül hozzuk létre a CRUD felhasználói felületet az átjáró projektben, amelyet az árajánlataink eléréséhez fogunk használni. A felhasználói felület összetevőinek előállításához ugyanazt a JDL fájlt fogjuk használni az "idézetek" mikroszolgáltatási projektből, és a JHipster's segítségével importáljuk. import-jdl parancs:

$ jhipster import-jdl ../jhipster-quotes/quotes.jh ... üzenetek kihagyva? Felülírja a webpack \ webpack.dev.js fájlt? y ... kihagyott üzenetek Gratulálunk, a JHipster végrehajtása befejeződött! 

Az importálás során a JHipster néhányszor felszólítja az ütköző fájlokkal kapcsolatos teendőket. Esetünkben egyszerűen felülírhatjuk a meglévő erőforrásokat, mivel még nem hajtottunk végre testreszabást.

Most újraindíthatjuk az átjárót, és megnézhetjük, mit teljesítettünk. Mutassuk a böngészőnket az átjáróra // localhost: 8080, ügyelve arra, hogy frissítsük a tartalmát. A Entitások menüben új bejegyzést kell tartalmaznia a Idézetek forrás:

Erre a menüpontra kattintva megjelenik a Idézetek listázási képernyő:

A várakozásoknak megfelelően a lista üres - még nem tettünk hozzá idézeteket! Próbálja meg hozzáadni egyet a képernyő jobb felső sarkában található „Új árajánlat létrehozása” gombra kattintva, amely a létrehozás / szerkesztés űrlapra vezet:

Láthatjuk, hogy a létrehozott űrlap minden elvárt tulajdonsággal rendelkezik:

  • A kötelező mezőket piros jelzővel jelölik, amely kitöltés után zöldre vált
  • A Dátum / Idő és a numerikus mezők natív összetevőket használnak az adatbevitel elősegítésére
  • Törölhetjük ezt a tevékenységet, amely változatlanul hagyja az adatokat, vagy elmenthetjük új vagy módosított entitásunkat

Miután kitöltötte ezt az űrlapot és megütötte Mentés, az eredményeket a listázási képernyőn látjuk. Most láthatjuk az újat Idézetek példaaz adatrácsban:

Rendszergazdaként hozzáférünk az API menüponthoz is, amely elvezet minket a szokásos Swagger API fejlesztői portálhoz. Ezen a képernyőn kiválaszthatjuk az elérhető API-k egyikét:

  • alapértelmezett: A Gateway saját API-ja, amely megjeleníti az elérhető útvonalakat
  • uaa: Fiók és felhasználói API-k
  • idézetek: Quotes API

8. Következő lépések

Az eddig felépített alkalmazás a várakozásoknak megfelelően működik, és szilárd alapot nyújt a további fejlesztéshez. A követelmények összetettségétől függően mindenképpen meg kell írnunk néhány (vagy sok) egyedi kódot. Néhány olyan terület, amely valószínűleg munkát igényel:

  • A felhasználói felület testreszabása: Ez általában nagyon egyszerű a front-end alkalmazás felépítésének köszönhetően - hosszú utat tehetünk meg egyszerűen a CSS-sel babrálva és néhány képet hozzáadva
  • A felhasználói adattár változásai: Egyes szervezetek már rendelkeznek valamilyen belső felhasználói adattárral (pl. LDAP könyvtár) - ehhez változtatásokra lesz szükség az UAA-n, de az a szép, hogy csak egyszer kell megváltoztatnunk
  • Részletesebb felhatalmazás a jogalanyokra:A létrehozott entitás-háttér által használt szabványos biztonsági modell nem rendelkezik semmilyen példányszintű és / vagy terepi szintű biztonsággal - a fejlesztő feladata, hogy hozzáadja ezeket a korlátozásokat a megfelelő szintre (API vagy szolgáltatás, az esettől függően)

Ezekkel a megjegyzésekkel is egy olyan eszköz használata, mint a JHispter, sokat segíthet egy új alkalmazás fejlesztésében. Ez szilárd alapot hoz magával, és a rendszer - és a fejlesztők - fejlődésével jó kódszintű konzisztenciát tarthat fenn.

9. Következtetés

Ebben a cikkben bemutattuk, hogyan lehet a JHispter használatával létrehozni egy működő alkalmazást egy mikroszolgáltatási architektúra és a JHipster UAA szervere alapján. Ezt úgy értük el, hogy egyetlen Java-kódot sem írtunk, ami meglehetősen lenyűgöző.

Szokás szerint az ebben a cikkben bemutatott projektek teljes kódja elérhető a GitHub adattárunkban.


$config[zx-auto] not found$config[zx-overlay] not found