Láttam egy videót a YouTube-on arról, hogyan lehet a névjegykártyát egy egyszerű NFC matricával intelligenssé tenni. A probléma az, hogy bár a matricára be lehet programozni egy vCard-ot, az iOS készülékek még nem támogatják ezt a funkciót. Az egyetlen módja annak, hogy egy iPhone olvassa az NFC vCard-ot, hogy a vCard fájlt a weben tároljuk. Ekkor jutott eszembe. Miért ne lehetne a vCard-ot az AWS-en hosztolni, kizárólag ingyenes erőforrásokat használva.

A nyilvánvaló megoldás a Lambda és Lambda Function URL-ek voltak, mivel ezek teljesen ingyenesek. Ráadásul biztos lehetsz benne, hogy az AWS még 5 vagy 10 év múlva is létezni fog, így a digitális névjegykártyád még mindig működni fog.
Emellett nagyon könnyen frissíthetjük adatainkat, ha valami megváltozik, nem kell újat vásárolnunk. Ami a környezetnek is jót tesz!

A fejlesztés során olyan problémákba ütköztem, amelyek miatt extra házirendeket kellett létrehoznom, hogy működjön. Mivel a lehető legegyszerűbbé akartam tenni, hogy mindenki használhassa, létrehoztam egy CloudFormation sablont, amely létrehozza az összes erőforrást .
Ha pedig már nincs rá szükség, a CloudFormation képes törölni az összes felhasznált erőforrást. De miért is tennéd ezt, amikor ez teljesen ingyenes.

A kódot Node.js 18.x-ben írtam, és egy v. 3.0 vCardot készít. Megkérdezheted, hogy miért nem v. 4.0, és a válasz egyszerű. Az Apple nem támogatja, és én a lehető legkompatibilisebbé akartam tenni.
A másik probléma, amivel szembesültem, hogy a vCard specifikáció szerint egy kép URL-címét is összekapcsolhatjuk a fotónkkal, de az Apple készülékek ezt sem támogatják. A fényképnek Base64 kódolva kell lennie a vCard-ban.
Ezért a CloudFormation létrehoz egy S3 Bucket-et (tárolót), ahol tárolhatjuk a fényképet (avatar.jpeg), a Lambda függvény pedig Base64-be konvertálja, és beépíti a kártyájába.

Nem csak az Apple-nek, az AWS-nek is vannak furcsa dolgai. Például, amikor létrehozol egy FunctionURL-t a Lambda függvényhez, ez az URL nincs definiálva a Lambda környezeti változójában. Ahhoz, hogy megkapd a FunctionURL-t, a GetFunctionUrlConfig szerepkört kell engedélyezned a függvény URL-jének olvasásához. Mivel a vCard lehetővé teszi a vCard forrásának meghatározását, ahonnan mindig a legfrissebb verziót kapja meg, létre kellett hoznom egy házirendet, és azt a Lambda szerepkörhöz csatolnom, hogy a FunctionURL-t a vCard-ban szerepeltessem.

A másik probléma, amivel szembesültem, hogy bár a Lambda kódot a CloudFormation-be be lehet illeszteni, az index.mjs fájl helyett index.js fájlt hoz létre, ami Node.js 18.x-hez szükséges. Van megoldás arra, hogy a kódot egy S3 tárolóba helyezzük el, és a CloudFormation lekérdezi onnan a kódot, de akkor ottragadunk abban a régióban, ahol az S3 tároló van. Ezért létrehoztam két CloudFormation sablont .
Ha a legegyszerűbb telepítést szeretnénk, és nem akarjuk megváltoztatni a régiót, használjuk az alapértelmezett sablont. Ez az USA keleti részén (Észak-Virginia) fog futni. Ha a névjegykártyáját egy másik régióban szeretnénk elhelyezni, használjuk helyette a template-with-code.yaml-t, de a kód működéséhez az index.js állományt index.mjs-re kell átnevezni.

A teljes forráskód elérhető a GitHubon Apache 2.0 licenc alatt. Részletes telepítési információkért lásd a GitHub oldalt.
Használjuk a template.yaml fájlt, ha a legegyszerűbb telepítést szeretnénk.
Ha meg szeretnénk adni a régiót, amelyben az erőforrások létrejöjjenek, használjuk helyette a template-with-code.yaml, és nevezzeük át az index.js forrásfájlt index.mjs-re.

Remélem, hogy ez a kis kód olyan hasznos, mint amilyen szórakoztató volt megírni.

A Ingyenes és egyszerű csináld magad digitális névjegykártya bejegyzés először Road to AWS-én jelent meg.

Lambda függvény létrehozása

Először is, hozzunk létre egy Lambda függvényt, mint az előző bejegyzésben, de ahelyett, hogy a Use a blueprint opciót választanánk, most az Author from scratch (Üres tervezet) opciót válasszuk. Adjunk egy nevet a függvényünknek. A Permissions alatt nem fogunk új szerepet létrehozni ehhez a függvényhez, hanem a meglévő szerepkörünket választjuk ki, amit a terveztünk hozott létre.

A Create function (Függvény létrehozása) gombra kattintás után a Lambda kódunk elkészül, és készen áll az API átjárónkkal való összekapcsolásra. Ehhez belépünk az API Gateway szolgáltatásba.

Szeretnénk ezt a funkciót új erőforrásként használni, ezért létrehozunk egy új erőforrást, és abban egy új módszert. A metódus beállításainál az előzőekhez hasonlóan kiválasztjuk az új Lambda függvényünket. Most már láthatjuk az API flow diagram-ot (folyamatábrázolási diagram) ahol szemléletesen láthatjuk, hogyan hajtódik végre az újonnan létrehozott Lambda függvényünk.

A Test gombra kattintva tesztelhetjük az új API-hívásunkat, és hogy minden rendben működik. Biztosak vagyunk benne?!

Minden rendben van?

Ne feledjük, hogy egy meglévő szerepet választottunk az új Lambda függvényünkhöz. A szerepkörünk rendelkezik az összes szükséges jogosultsággal?

Ha visszamegyünk a Lambda-hoz, és megnézzük a Monitor részt, nem látunk hibát.

A CloudWatch naplók megtekintése gombra kattintva viszont hibaüzenetet kapunk.

Ez azt jelenti, hogy a naplózás jelenleg nem működik az új Lambda függvényünkön. Manuálisan kell létrehoznunk egy naplócsoportot, és engedélyeznünk kell a szerepkörünknek, hogy ebbe a naplóba írjon.

A CloudWatch konzolban válasszuk a Log groups (naplócsoportok) menüpontot, majd kattintsunk a Create log group (naplócsoport létrehozása) gombra, és nevezzük el a naplócsoportunkat pontosan úgy, ahogy a hibaüzenetben szerepel. Esetünkben: /aws/lambda/simple-api-auth

A naplócsoport létrehozásakor ne felejtsük el feljegyezni az ARN-jét, mert később szükségünk lesz rá.

Most, hogy engedélyeztük a szerepkörünknek, hogy írjhasson ebbe a naplócsoportba, el kell mennünk az IAM-be, és módosítanunk kell a szerepkörünket. Látjuk, hogy a CloudWatch engedélyek az AWSLambdaBasicExecutionRole házirendben vannak.

Most kiválasztjuk ezt a házirendet, és az Edit policy (Házirend szerkesztése) gombra kattintunk. Az erőforrások szakaszban az Add ARN (ARN hozzáadása) gombra kattintunk, és hozzáadjuk az újonnan létrehozott naplócsoportok ARN-jét. Mentsük el a házirendet.

És kész is vagyunk! Hozzáadtunk egy új funkciót az API-átjárónkhoz, és beállítottuk a szükséges jogosultságokat.

Tanulságok:

• Tartsuk karban a jogosultságokat az IAM-ben. Adjuk meg a haznált erőforrásokat, és csak a szükséges házirendeket engedélyezzük.

A Lambda függvény hozzáadása API-átjáróhoz bejegyzés először Road to AWS-én jelent meg.