RESTful API Backend építése hitelesítéssel az Elixir Phoenix segítségével

Payam Mousavi

2018. november 11. · 9 perc olvasás

Pár év után a Ruby On Rails-szel együttműködve - hatalmas rajongó vagyok! - Úgy gondoltam, itt az ideje, hogy megtanuljak egy másik webes keretet, és miután némi kutatást végeztem, az Elixirt és a Phoenix-et választottam sok okból, például a teljesítmény, a késés és természetesen az Erlang VM miatt. Úgy gondolom, hogy a Ruby fejlesztői elképesztőnek és könnyen megtanulhatónak találják ezt az erős keretrendszert, mivel a szintaxis valóban közel áll ahhoz, amit a Ruby kínál.

Ebben az oktatóanyagban egy REST API háttérrendszert készítünk a Phoenix használatával. Néhány remek csomagot is felhasználunk majd a felhasználók hitelesítéséhez és felhatalmazásukhoz, hogy hozzáférjenek az API -inkhoz.

Telepítenie kell az Elixirt és a Phoenix-et. Az Elixir 1.7.3 és a Phoenix v1.3.4 verziókat használom. A verziókat a következő futtatással ellenőrizheti:

Hozzuk létre az első Phoenix JSON API alkalmazást a következő parancs futtatásával:

Most hoztuk létre az alkalmazást HTML-megjelenítés és eszközépítés nélkül, mivel nincs szükségünk statikus tartalom megjelenítésére.

Most nyissa meg a config/dev.exs fájlt és látni fogja, hogy az alkalmazás a 4000-es porton fut. Az alapértelmezett adatbázis-adapter a Phoenix alkalmazás létrehozásakor a Postgres. Frissítse PostgreSQL hitelesítő adatait:

Vissza a terminálhoz, futtassa az alábbi parancsokat az alkalmazás adatbázis létrehozásához és a kiszolgáló indításához:

Ha hibát lát a plug_cowboy kapcsán, adja hozzá a csomagot a mix.exs fájlhoz:

Futtassa a mix deps.get fájlt a csomag telepítéséhez, majd a mix phx.server használatával indítsa újra a szervert és látogasson el a http: // localhost: 4000 oldalra. Hiba jelenik meg:

Ez azért van, mert még nem határoztunk meg egyetlen útvonalat sem! Most határozzunk meg egy egyszerű index útvonalat. Frissítse a router.ex fájlt mint ez:

Hozzáadtuk a pipeline: böngészőt hogy lehetővé tegye a HTML kérések kezelését. A csővezetékekről itt olvashat bővebben. Most hozzuk létre a lib/busi_api_web/controller/default_controller.ex fájlt:

Most töltse be újra az oldalt, és nem fog hibát látni, csak egy egyszerű szöveget.

Az Elixir mix számos hasznos generátorral érkezik, és vannak olyan Phoenix-specifikusak, amelyek erőforrásokat hoznak létre. Futtassa a terminálon a következő parancsot, és ellenőrizze a beépített generátorokat:

Tegyük fel, hogy szeretnénk egy listát az aktív vállalkozásokról. A JSON API-k létrehozásához a modellünkkel a phx.gen.json mixet kell használnunk . Essünk neki:

Megkérdezheti: „Mi az a könyvtár?”. A Phoenix 1.3-ban volt néhány változás a régebbi verziókhoz képest. Az egyik ilyen változás az, hogy lehetővé teszi számunkra a tartományi logika szétválasztását különböző moduloknak, amelyeket kontextusnak nevezünk. Tehát úgy döntöttünk, hogy az üzleti modellünkkel (és valószínűleg más erőforrásokkal) kapcsolatos minden logika megtalálható a Könyvtárban kontextus, amely egy külön mappa a projektben.

A mix parancs csak létrehozott egy fájlkészletet, beleértve a vezérlőt és az áttelepítési fájlt, valamint néhány tesztfájlt. Ezután a Phoenix megkéri, hogy adjuk hozzá ezt az erőforrást a lib/busi_api_web/router.ex fájlhoz és frissítse az adatbázist a mix ecto.migrate paranccsal:

Futtassuk a phx.routes keveréket az útvonalak megtekintéséhez:

Mielőtt tesztelnénk az API-kat, adjunk hozzá néhány kezdeti magadatot. Nyissa meg a priv/repo/seed.exs fájlt és adja hozzá ezeket a sorokat:

Most futtassa a mix run priv/repo/seed.exs fájlt. Csak álnevet használtunk hogy 2 álnevet hozzon létre a Repo számára és üzleti modulok felhasználásával őket rekordok létrehozására. Indítsa újra a szervert, és nyissa meg a http: // localhost: 4000/api/business címet a JSON-rekordok megtekintéséhez.

Ha új rekordot szeretne létrehozni a POST API használatával, futtassa a terminálon ezt a curl parancsot (vagy használja a Postmant):

Vegye figyelembe, hogy az „üzleti” adatokat továbbítjuk mező, mivel az API arra számít, hogy paramétereket küldenek az adott mezőbe (Check business_controller.ex).

Ideje megvizsgálni a kódot! Ebben a történetben egy fantasztikus kezelőt fog látni, amelyet pipának hívnak (|>), amely többfunkciós hívások esetén igazán hasznos. Érdemes egy kicsit elolvasnia a minták illesztését is mielőtt folytatnánk.

Kezdjük a BusinessControllerrel. Most ismerkedtünk meg az aliasról, ezért ezt kihagyjuk. 5 műveletünk van (API), beleértve az indexelést, a megjelenítést, a létrehozást, a frissítést és a törlést. Ezek a műveletek hívnak néhány funkciót a Directory-ból modul az adatobjektumok beolvasására/kezelésére. Például list_businesses () a modulban visszaadja az üzleti táblázat összes rekordját:

Töltsön el egy kis időt ezeknek a moduloknak az ellenőrzésével, hogy jobban megértsék, mi történik a Phoenix alkalmazás adatrétegében.

Egy másik érdekes funkció az action_fallback amely némi magyarázatot igényel. Alapvetően egy cselekvési tartalékot használnak a kód egyszerűbbé tételéhez, hogy ezeknek a Repo funkcióknak a sikerességére koncentrálhassunk. Ha valami rossz történik (például adatellenőrzés vagy korlátozások megsértése), az action_fallback utasítás meghívja a megfelelő függvényt a FallbackControllerből, különben az erőforrás létrejön vagy frissül. A utasítás csak a duplával törődik, így működik a legtöbb modulfunkció:

Például a create_business a function egy ilyen duplát adhat vissza egy sikeres állapot után:

vagy hibaállapot:

Ezt hívjuk Changeset-nek amelyet még megbeszélünk. Ezt tesztelheti az iex -S mix futtatásával a terminálon és:

Most ellenőrizzük az üzleti modellünket:

A mezők és adattípusaik meghatározása mellett van egy változáskészlet is funkció és feladata a bemeneti paraméterek leadása a modellmezőkbe és azok érvényesítése. Így például futtathatjuk az előző curl parancsot, de ezúttal a „tag” mező átadása nélkül. Ezt a hibát fogja látni:

Az utolsó dolog, amit át szeretnénk nézni, az a JSON nézet, amely a kimeneti adatokat az API-k segítségével biztosítja. Nyitott nézetek/business_view.ex:

Ha módosítani szeretné a kimenetet, vagy további mezőket szeretne hozzáadni (például időbélyegző mezők: insert_at, updated_at), akkor itt kell frissítenie a kódot. Ez a modul egy jó módszer arra is, hogy sok adatrekordot jelenítsen meg a render_many értékkel. Frissíthetjük a render funkciót, hogy visszatérjen a insert_at értékre terület:

NaiveDateTime-t használtunk modul a dátum és az idő karakterláncokká alakításához. Frissítse a http: // localhost: 4000/api/business alkalmazást az eredmény megtekintéséhez.

Nem akarok itt a TDD-ről beszélni, mert ehhez még egy teljes cikkre van szükség. De futtassuk tesztjeinket, hogy ellenőrizzük, minden rendben van-e. Először hozza létre a tesztadatbázist, és futtassa az áttelepítéseket:

Látni fogja, hogy 2 hiba van, mert újabb mezőt adtunk üzleti JSON kimenetünkhöz:

Javítsuk ki őket. Nyissa meg a/busi_api_web/controllers/business_controller_test.exs tesztet és frissítse ezt az állítási állítást, amelyet 2 tesztesetben használnak, írja le az „üzlet létrehozása” leírást és írja le a „frissítési üzletet”:

Most futtassa a mix tesztet újra, és látni fogja, hogy az összes tesztet sikeresen teljesítették.

Eddig egy RESTful háttérprogramot építettünk néhány API-val a CRUD erőforrásunkhoz. Most korlátozni akarjuk az API-khoz való hozzáférést azáltal, hogy csak regisztrált felhasználók számára engedélyezzük azok elérését. Gyám egy Elixir csomag a hitelesítéshez. Szükségünk van Comeoninra is a jelszó titkosításához. Vegyük fel őket a mix.exs függőségek listájára. A Bcrypt-et is használjuk mint hash algoritmusunk:

Most futtassa a mix deps.get fájlt hogy telepítse azokat a csomagokat. A felhasználók kezeléséhez létre kell hoznunk egy másik JSON-erőforrást (bár nem fogjuk használni az összes műveletet, könnyebb a generátorokat használni):

Frissítse az útválasztót, hogy tükrözze a felhasználói API-kat (regisztráció és bejelentkezés):

Ezután futtassa a mix ecto: migrate programot felhasználói tábla létrehozásához.

Nyissa meg a lib/busi_api/accounts/user.ex fájlt néhány változtatásra:

Tehát egy új mezőt adtunk a felhasználói sémához - jelszó - ami egy virtuális mező. Mint sejtette, ez az új mező nem marad meg az adatbázisban, de az érvényesítési folyamathoz használjuk. titkosított jelszó menti a DB. Emellett frissítettük a változáskészletet funkció az érvényesítéshez és a formátum ellenőrzéséhez. A jelszó titkosításához, létrehoztunk egy privát függvényt - put_hashed_password - a jelszó kivonása a Comeonin/Bycrypt segítségével. Ez a függvény megkapja a changeset (nem állandó felhasználói objektumot) és frissíti a encrypted_password szót ha a változáskészlet érvényes.

Hozzunk létre egy felhasználót, hogy megbizonyosodjunk a fenti kód működéséről! A terminálon futtassa az iex -S mixet:

Az API-t tesztelheti a curl használatával is:

Most importáljuk be megfelelően a Guardiant! Nyissa meg a config/config.exs fájlt és adja hozzá ezt a fájl végéhez:

Cserélje le a SECRET szót a mix guardian.gen.secret kimenetére.

Ezután hozzá kell adnunk egy auth modult a Guardian használatához (a JWT az alapértelmezett token típus). Hozzon létre lib/busi_api_web/auth/guardian.ex fájlt:

Ez a modul segíti a tokenek létrehozását, azok dekódolását, a tokenek frissítését és visszavonását. Most nyissa meg a user_controller.ex fájlt és adj hozzá egy álnevet ehhez a modulhoz:

És frissítse a létrehozási műveletet, és távolítsa el a többi műveletet, mivel itt nincs rájuk szükségünk (indexelés, mutatás, frissítés, törlés):

Hozzáadtunk egy Guardian funkciót egy JWT token létrehozásához a felhasználó létrehozása után. A „user.json” -t is rendereljük hogy a válasz részeként elküldje a JWT tokent. De frissítenünk kell a nézetet. Nyissa meg a lib/busi_api_web/views/user_view.ex fájlt és frissítse:

Most hívja meg az API-t:

amely így válaszol:

Hozzunk létre egy másik API-t a felhasználók számára a bejelentkezéshez. Először létre kell hoznunk egy új függvényt a lib/busi_api/accounts/accounts.ex fájlban e-mail alapján visszaküldeni a felhasználót:

Most szükségünk van egy funkcióra a felhasználó hitelesítéséhez. A lib/busi_api_web/auth/guardian.ex könyvtárba tettük:

Amint észrevetted, 3 funkciót adtunk hozzá annak érdekében, hogy e-mailben eljussunk egy felhasználóhoz, a checkpw segítségével ellenőrizzük, hogy a jelszó egyezik-e a titkosított jelszóval Comeonin funkcióját, és végül hozza létre a tokent. Nézze meg, hogyan használtuk a mintaillesztést a token megszerzéséhez a Guardian encode_and_sign nevéből funkció:

Ahogy újabb hibaállapotot adtunk hozzá - jogosulatlan - frissítenünk kell a fallback_controller.ex fájlt ennek az állapotnak a fogadásakor jár el egy másik hívási funkció hozzáadásával:

Hozzon létre egy műveletet a user_controller.ex fájlban:

Most tesztelje az API-t:

Most, hogy engedélyeztük a hitelesítést az alkalmazásunkban, korlátozhatjuk bizonyos forrásokhoz való hozzáférést a Guardian Pipelines segítségével. Készítsük el a pipeline modulunkat a lib/busi_api_web/auth/pipeline.ex fájlban:

És egy modul a hibakezeléshez a lib/busi_api_web/auth/error_handler.ex fájlban:

Most hozzá kell adnunk egy új csővezetéket a router.ex fájlhoz:

És frissítse az api hatókörét:

Tehát hozzáadtuk a hitelesítést az API-khoz, amelyeknek korlátoznunk kell a hozzáférést. Most, ha az/api/vállalkozásokat hívja, hitelesítetlen hibát fog kapni:

Az eredmény eléréséhez el kell küldenie JWT tokent - amelyet a bejelentkezés után kapott -:

Vegye figyelembe, hogy a HTTP hordozó jogosultságát használjuk.

Gratula! Az alkalmazás készen áll.

Ellenőrizheti a többi Guardian funkciót abban az esetben, ha például hozzáférnie kell az aktuális felhasználóhoz vagy visszavon egy tokent a kijelentkezéshez:

Az Elixir/Phoenix segítségével létrehoztunk egy RESTful háttérprogramot amely feltár néhány CRUD és hitelesítési API-t. Az API eléréséhez a felhasználónak regisztrálnia és bejelentkeznie kell, hogy JWT tokent kapjon. A Guardiant használtuk és Comeonin hitelesítés és hitelesítés céljából.

Remélem tetszett ez a cikk. A forráskódot letöltheti a Github oldalamról: pamit/elixir-phoenix-json-api.