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.

A Mastodon-t választottam elsődleges platformnak, mert ez a legnépszerűbb az összes közül. Választhatsz mást is, mivel ezek a hálózatok zökkenőmentesen tudnak egymással kommunikálni, függetlenül attól, hogy milyen szervert futtatnak.

A Twitter (ma: X) kereskedelmi vállalatként jogosult korlátozni vagy kereskedelmi forgalomba hozni az API-ját, ami nehézséget jelenthet a startupok vagy kis fejlesztők számára. A Mastodon nemcsak ingyenes és nyílt forráskódú, hanem sokkal fejlesztőbarátabb is. Az egyik ilyen funkció a botfiókok támogatása. Ezek a fióktípusok nincsenek korlátozva, sőt, bátorítják a használatukat. A Mastodon-ban külön megjelölhetjük, hogy egy fiók bot-e, így mindenki számára átláthatóbbá válik.

Az első lépés mindig a legnehezebb, a Mastodon szerver kiválasztása. Rengeteg közül választhatunk, némelyik speciális közösségek számára van fenntartva, némelyik pedig földrajzilag korlátozott. Ha bizonytalan vagy, maradj a legrégebbi mellett: mastodon.social.

Hozzonunk létre egy fiókot itt, és jelöljük be a This is an automated account (ez egy automatizált fiók) négyzetet a profilunk alatt. Ez tudatja a többiekkel, hogy ez egy botfiók. Az Under Development (fejlesztés alatt) hozzunk létre egy új alkalmazást, és válasszuk ki a megfelelő jogosultságokat. Mivel az én botom csak publikálni fog, csak a write:statuses opciót választottam.

Egy korábbi blogbejegyzésemben létrehoztam egy honlapot a magyar techkonferenciáknak. Ezt fogom használni input forrásként. Jelenleg ez az oldal nem kínál egyszerű módot az információk exportálására, ezért módosítottam a Jekyll kódot, hogy CSV fájlt generáljon a közelgő eseményekről. Így könnyebben tudom felhasználni az adatokat.

A serverless megközelítés

A bejegyzés címéből valószínűleg kitaláltad, hogy serverless megközelítést fogok alkalmazni. Nem akarok biztonsági frissítésekkel és javításokkal foglalkozni. Csak azt szeretném, hogy ez a bot nagyon kevés karbantartással működjön.

Tipp: Válaszd az arm64-et Lambda architektúrát, mert annak olcsóbb a futtatása.

A Mastodonhoz egy maroknyi API kliens közül választhatunk. Mivel Node.js 18.x-et fogok használni, olyan klienst akartam találni, amely kompatibilis vele. A választásom a Masto.js-re esett, amelyet elég gyakran karbantartanak, és amely támogatja a Mastodon API legtöbb funkcióját.

A techconf.hu CSV-adatainak letöltéséhez az Axios-t fogom használni, mint a korábbi projektjeimben. A CSV adatok elemzésére a választásom a csv-pars-re esett (vigyázz, többféle CSV-parser létezik, egyes nevek csak kötőjellel különböznek egymástól). Ezután minden egyes funkcióhoz külön Layer-t hoztam létre, és csatoltam a Lambda függvényhez.

Az egészet működésre bírni

A kód nagyon egyszerű. Először letöltöm a CSV fájlt, és a csv-parse segítségével elemzem. Ezután beállítom a Tootot (a Mastodon kifejezése a Tweetre) és közzéteszem a Masto.js segítségével.

Az egyik probléma, amivel szembesültem, hogy a Mastodonban minden Tootnak van egy nyelvi változója. Ha nem állítod be külön, akkor a Mastodon fiókodban beállított nyelv lesz az alapértelmezett.

Tipp: Mivel a Fediverse annyira decentralizált, jó ötlet, ha minden hozzászólásodat megjelölöd.

import { parse } from 'csv-parse';
import { login } from 'masto';
import axios from 'axios';

export const handler = async(event) => {
    var tweet = "Upcoming Hungarian Tech Conferences 🇭🇺\n\n";
    var conferencesThisWeek = false;
    const currentDate = new Date();
    const endOfWeek = new Date(new Date().setDate(new Date().getDate() + 7));
    currentDate.setHours(0,0,0,0);
    endOfWeek.setHours(0,0,0,0);
    var conferenceDate;
    var csv;
    
    await axios({
        url: 'https://techconf.hu/conferences.csv',
        method: 'GET',
        responseType: 'blob'
    }).then((response) => {
        csv = response.data;
    });
    
    const parser = parse(csv, {
        delimiter: ",",
        from_line: 2
    });
    
    for await (const record of parser) {
        conferenceDate = new Date(record[3]);
        if (currentDate <= conferenceDate && conferenceDate <= endOfWeek) {
            tweet += '👉 ' +record[0] + ' (' + record[2] + ')\n📅 ' + record[3] + ' - ' + record[4] + '\n🔗 ' + record[1] + '\n\n';
            conferencesThisWeek = true;
        }
    }
    
    if (conferencesThisWeek) {
        tweet += '#Hungary #Technology #Conference';
        
        const masto = await login({
            url: 'https://mastodon.social/api/v1/',
            accessToken: ''
        });
    
        await masto.v1.statuses.create({
            status: tweet,
            visibility: 'public',
            language: 'en'
        });
    }
    
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

Időzítés

A Lambda függvény ütemezésének legegyszerűbb módja az Amazon EventBridge Scheduler (ütemező) használata. Egyszerűen válasszuk ki az ütemezési mintát és a Lambda függvényt célként, és a megadott időpontban végrehajtja a kódot.

Végső gondolatok

Említettem már a legjobb részt? Mindez ingyen van. Az általam használt szolgáltatások mindegyike az AWS Free Tier (ingyenes) szolgáltatási körébe tartozik (jelen íráskor).

Nyugodtan hozzatok létre hasonló botokat, vagy segítsetek jobbá tenni a kódomat, vagy csak kövessétek a botomat a következő címen: https://mastodon.social/@techconf

A Serverless Mastodon bot bejegyzés először Road to AWS-én jelent meg.

Az alapok: S3 statikus weboldal hosting

Statikus webhely tárhelyet még soha nem volt ilyen egyszerű létrehozni. Az Amazon S3 statikus tárhelyszolgáltatással egyszerűen feltölthetjük statikus oldalainkat egy S3 tárolóba, és engedélyezhetjük a nyilvános hozzáférést (az S3 tárhelyet mindenképpen nevezzük el a domain nevének megfelelően). Az interneten rengeteg cikket találhatunk, amelyek elmagyarázzák, hogyan kell beállítani az S3 statikus tárhelyet, ezért itt nem fogok további részletekbe bocsátkozni.

De vannak korlátok: Az S3 nem támogatja a HTTPS-t, ami a weboldalak tárhelyének de facto minimum feltétele. A HTTPS használatához be kell állítani az Amazon CloudFrontot. Ez rengeteg extra funkcióval jár, mint például GeoIP-korlátozás, gyorsítótárazás és ingyenes SSL-tanúsítvány. Arról nem is beszélve, hogy végre letilthatjuk az S3 nyilvános hozzáférését (ami biztonsági kockázatot jelenthet), és korlátozott hozzáférést adhatunk csak a CloudFrontnak (egy S3 házirenddel).

Pro tipp: Adjuk hozzá a CloudFront ListBucket engedélyeket az S3 tároló házirendjéhez, különben az ügyfél nem fog HTTP státuszkódokat kapni, beleértve a 404-es kódot is, amikor nem létező tartalomhoz próbál hozzáférni:

Mishi

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::roadtoaws.com",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        },
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::roadtoaws.com/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        }
    ]
}

A CloudFront gyorsítótárazása miatt nem ideális fejlesztéshez. Vagy helyben kell tesztelni a kódot, vagy a HTTPS engedélyezése nélkül. Ez a fő oka annak, hogy továbbra is jó lenne, ha az S3-ban is megjelenne a HTTPS-támogatás.

Legyen dinamikus

A statikus weboldalak már a múlté. Valószínűleg előbb-utóbb valamilyen dinamikus tartalomra lesz szükségünk. Bár sok olyan szolgáltatás létezik, amely olyan funkciókat biztosít, mint az e-mail küldés, a megjegyzések, amelyeket beilleszthetünk a statikus kódunkba, hogy dinamikussá tegye azt, valószínűleg saját kódot kell írniunk bizonyos funkciókhoz. Itt jönnek jól a Lambda Function URL-ek. Egy egyszerű Lambda függvénnyel kódot hajthatunk végre vagy más AWS-erőforrásokat használhatunk, amelyeket egy egyszerű HTTP-kérelemmel hívhatunk meg a böngésződben. De hogyan korlátozhatjuk ezt egy adott IP-re, tartományra vagy a CloudFrontra?

Az AWS az IAM-en keresztül történő hitelesítést ajánlja, és bár ez valóban biztonságos módszer, a fejlesztést kihívássá teszi. Az első dolog, amit láthatsz, az a CORS, ahol az eredetet egy tartományra állíthatod be. Sajnos ez nálam nem úgy működött, ahogy szerettem volna. Ez nem korlátozza a Lambdádat abban, hogy bármilyen IP-ről meg lehessen hívni. Itt beállíthatsz egy X-Custom fejlécet is, de ez sem igazán korlátozza a külső hozzáférést.

Ezután kerestem megfelelő IAM-engedélyeket, amelyeket a Lambda-funkciókhoz csatolhatok. A rendelkezésre álló házirendek között találtam az InvokeFunctionUrl-t, ahol hozzáadhatunk egy IP-címet, hogy a meghívást egy adott IP-re korlátozza. Ez remekül hangzik! Létrehozunk egy házirendet, és csatoljuk azt a Lambda Role-hoz. Sajnos ez sem korlátozza a Lambda hozzáférését.

Mi volt tehát a megoldásom?

1. Korlátozás kódban

Az első kézenfekvő megoldás a forrás IP-jének ellenőrzése a Lambda függvénnyel. Íme egy Node.js nyelvű mintakód (hasonló kódot más nyelvekhez is találhatsz az interneten):

const ipAddress = event.identity.sourceIP;

if (ipAddress === '52.84.106.111') {
  const error = {
      statusCode: 403,
      body: JSON.stringify('Access denied'),
  };
  
  return error;
} else {
  const hello = {
      statusCode: 200,
      body: JSON.stringify('Hello World!'),
  };
  
  return hello;
}

Bár ez nyilvánvalóan működik, extra kódot adsz hozzá egy olyan Lambda-funkcióhoz, amelynek elsődleges szerepe valami más elvégzése. Arról nem is beszélve, hogy ez növeli a futási időt és a Lambda által használt erőforrásokat. A legfontosabb, hogy hogyan lehetsz biztos abban, hogy a sourceIP változóban kapott IP valóban az az IP, ahonnan az ügyfél érkezik.

A legnagyobb gondom ezzel a megoldással az volt, hogy nem csak egy adott IP-re akartam korlátozni a funkcióimat, hanem az egész CloudFront disztribúcióra, így biztos lehetek benne, hogy az egyik statikus oldalamról hívják meg. Ezzel a módszerrel nagy gondot jelentene az összes CloudFront szerver naprakész listájának karbantartása.

2. reCAPTCHA

Igen, jól hallottad, Google reCAPTCHA. Ez elsőre furcsán hangozhat, de ez az a megoldás, amit én a munkám során megvalósítottam, és megoldást nyújt a fenti kihívásokra.

A reCAPTCHA kód beágyazása statikus weboldalakba jó ötlet. Valójában a Google azt javasolja, hogy a kódot minden oldalra építsük be – nem csak azokra, amelyeken szükség van rá, például az űrlapok érvényesítésére -, mert így az algoritmus hatékonyabban tudja felismerni a csalárd használatot. A lambda függvényen belül most már validálhatom, hogy a felhasználó valóban meghívta-e a statikus weboldalamról a lambda függvényem URL-címét. Íme a kód, amelyet a reCAPTCHA-kérés ellenőrzésére használok:

const gRecaptchaResponse = event.queryStringParameters["g-recaptcha-response"];
    
    var verificationUrl = "https://www.google.com/recaptcha/api/siteverify?secret=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&response=" + gRecaptchaResponse;
    const recaptchaResult = await getRequest(verificationUrl);
    
    if (false == recaptchaResult.success || 0.5 > recaptchaResult.score) {
      return error;
    }

Végezetül

Az S3 statikus weboldal hosting a legegyszerűbb módja a serverless utazás megkezdésének. Bár vannak akadályok, mindig találhatsz serverless megoldást.

A AWS Lambda Function URL-ek korlátozása CloudFronthoz bejegyzés először Road to AWS-én jelent meg.

A lambda környezeti változók olyan karakterláncok kulcspárjai, amelyek a függvény verzió-specifikus konfigurációjában tárolódnak. Ez utóbbi akkor fontos, ha verziókezelést használunk a Lambdában. Egyelőre a kulcspáros részre koncentrálunk, a Lambda verziókról később beszélünk.

Környezeti változók definiálása

A környezeti változókat a Configuration (konfiguráció) fül, Environment variables (környezeti változók) szakaszában adhatjuk meg.

Az Edit (szerkesztés) gombra kattintva beállíthatjuk a környezeti változó kulcsát és értékét. Ehhez a bemutatóhoz hozzunk létre két változót: egyet a felhasználónév, egyet pedig a jelszó tárolására.

A Mentés gombra kattintás után a környezeti változók létrejönnek és elérhetővé válnak a Lambda futtatási időn keresztül. A folyamat környezetével érhetjük el őket, így:

const username = process.env.username;
const password = process.env.password;

Kulcs létrehozása titkosításhoz

A jelszavunk egy nagyon érzékeny információ, és szeretnénk úgy módosítani a kódunkat, hogy csak a Lambda kódunk tudja visszafejteni. A környezeti változók támogatják a titkosítást az AWS Key Management Service (KMS) segítségével.

Menjünk a KMS konzolra, és hozzunk létre egy új kulcsot. A Customer managed keys (ügyfél által kezelt kulcsok) alatt kattintsunk a Create key (kulcs létrehozása) gombra.

Ezután a kulcs típusát szimmetrikusra állítjuk be, és a kulcsunkat „simple-api-key”-nek nevezzük el az Alias alatt. Az alias bármikor megváltoztatható. Oktatási célokból egyelőre ne határozzuk meg a kulcs adminisztrációs és kulcshasználati jogosultságait.

Lambda környezeti változók titkosítása KMS segítségével

Most, amikor visszamegyünk a Lambdába, jelöljük be a Enable helpers for encryption in transit opciót. Minden változó mellett megjelenik egy új Encrypt (titkosítás) gomb. Az Encrypt gombra kattintva most már kiválaszthatjuk az újonnan létrehozott kulcsunkat.

A változó dekódolása

Ha megnézzük a változót, vagy kiíratjuk az értékét a Lambdából, akkor valami ilyesmit látunk:
AQICAHhc385PwJyf/tV5ZOhskZFcr5b6NMe/u3YFxJEWOhlnxQG776g/ozncvTV1p5KoSQucAAAAZzBlBgkqhkiG9w0BBwagWDBWAgEAMFEGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMGdpuISr9cRZoNj8TAgEQgCTHd1A1f6zmXa7cCbt8Q9UJqSetCvZ6m/I8VZuLC54k/0934ZE=

A dekódoláshoz két dologra van szükségünk:

1. a változó visszafejtése a KMS Decrypt művelettel
2. engedélyezzük a függvényünknek a KMS Decrypt művelet meghívását.

Először is módosítsuk a kódunkat a változó dekódolásához. Íme egy mintakód:

const plainUsername = process.env.username;
const encryptedPassword = process.env.password;
let decryptedPassword;

if (!decryptedPassword) {
    const kms = new AWS.KMS();
    try {
        const req = {
            CiphertextBlob: Buffer.from(encryptedPassword, 'base64'),
            EncryptionContext: {
                LambdaFunctionName: process.env.AWS_LAMBDA_FUNCTION_NAME
            },
        };
        const data = await kms.decrypt(req).promise();
        decryptedPassword = data.Plaintext.toString('ascii');
    } catch (err) {
        console.log('Decrypt error:', err);
        throw err;
    }
}

A kód végrehajtásakor hibát kapunk a CloudWatch-ban:

„errorType”:”AccessDeniedException”,”errorMessage”:”The ciphertext refers to a customer master key that does not exist, does not exist in this region, or you are not allowed to access.”

A környezeti változó visszafejtéséhez a függvényünknek hozzáférésre van szüksége a titkosításhoz használt kulcshoz. Menjünk vissza még egyszer a KMS konzolhoz, és módosítsuk a Kulcsfelhasználókat. Most hozzáadjuk a Lambda végrehajtó szerepkörünket a kulcsfelhasználókhoz. A mi esetünkben a simple-api-role-t.

És kész! Sikeresen létrehoztuk a Lambda környezeti változókat, amelyeket most már több forrásfájlban is használhatunk, és biztosítottuk a jelszavunkat a KMS-szel!

A Lambda környezeti változók használata bejegyzés először Road to AWS-én jelent meg.

Cognito User Pools (felhasználói csoportok)

Az Amazon Cognito egy egyszerű és biztonságos felhasználói regisztrációs, bejelentkezési és hozzáférés-szabályozási eszköz. Képes a felhasználói és az azonossági poolok kezelésére. A felhasználói poolok olyan felhasználói könyvtárak, amelyek regisztrálási és bejelentkezési lehetőségeket biztosítanak az alkalmazás felhasználói számára. Az Identity poolok AWS hitelesítő adatokat biztosítanak, amelyekkel a felhasználók hozzáférhetnek más AWS-szolgáltatásokhoz.

Az API-átjárónkhoz létrehozunk egy Cognito felhasználói csoportot, amely az összes engedélyezési feladatot, beleértve a felhasználónevek, jelszavak és hozzáférési tokenek kezelését is, kezeli.

Kezdjük a Cognitóval és válasszuk a Manage User Pools (felhasználói csoportok kezelése) lehetőséget. Itt válasszuk a Create a user pool-t (felhasználói csoport létrehozása). Nevezzük el a poolunkat simple-api-AUTH-nak, és tekintsük át a Step through settings-et (lépésről lépésre beállításokat), ahogy testre szabjuk a poolunkat. Ne feledjük, hogy ezeket az attribútumokat nem tudjuk megváltoztatni, miután létrehoztuk a pool-t. A házirendek és egyéb pool-beállítások később is módosíthatók, de az attribútumok nem. Amikor az „Alkalmazás-ügyfél” beállításoknál vagyunk, létrehozunk egy új alkalmazás-ügyfelet az API-átjárónkhoz.

Itt állítjuk be az App kliensünket. Az egyszerűség kedvéért kikapcsoljuk a Generate client secret opciót, és engedélyezzük az ALLOW_ADMIN_USER_USER_PASSWORD_AUTH opciót, amelyre szükségünk lesz a Lambda függvényünk eléréséhez.

A felhasználói csoportunk most már készen áll. Ilyen egyszerű .

Felhasználó hozzáadása Cognito felhasználói csoporthoz

Több lehetőségünk is van arra, hogy felhasználókat hozzunk létre a felhasználói készletünkben. Az alapértelmezett beállítások lehetővé teszik a felhasználók számára, hogy saját magukat regisztrálják. Létrehozhatunk egy egyszerű felhasználói felületet, vagy engedélyezhetünk más személyazonosság-szolgáltatókat, mint például a Facebook vagy a „Sign in with Apple”. Az egyszerűség kedvéért a felhasználót manuálisan hozzuk létre a Users and groups (felhasználók és csoportok) alatt.

Miután létrehoztuk a felhasználót, a felhasználó kap egy e-mailt a következő információkkal:

Your username is misi and temporary password is 00eEhtI;.

Úgy tűnik, hogy minden készen áll a Cognito-ban, de ha jobban megnézzük, akkor láthatjuk, hogy a felhasználó még nincs aktiválva. A fiók státusza a következő: FORCE_CHANGE_PASSWORD .

Ezt nem tudjuk megváltoztatni a Cognito felhasználói felületen, ezért ezt inkább a Lambda-ban fogjuk megtenni.

API átjáró csatlakoztatása Cognito-hoz

Most visszamegyünk az API-átjárónkhoz, és kiválasztjuk az Authorizers lehetőséget. Itt válasszuk a Create new authorizer -t (új engedélyező létrehozása).

Kiválasztjuk, hogy a típus Cognito legyen, és kiválasztjuk a korábban létrehozott Cognito felhasználói csoportunkat. A token forrását elnevezheted, ahogyan csak akarod, de a következő szabványok miatt Authorization-nek nevezzük el.

API-metódus biztosítása Cognitóval

Kezdjük el a metódusaink biztosítását a Cognito engedélyezésével. A korábban létrehozott hello erőforráson belül a GET metódust fogom kiválasztani. Ehhez a metódushoz már korábban beállítottuk az API kulcsokat, ezért eltávolítom a szükséges API kulcs opciót, és a Cognito-t választom az engedélyezésünkhöz.

Ha megnézzük a módszerünket, akkor láthatjuk, hogy a Cognito az Authorizer.

Auth függvény előkészítése hitelesítéshez

Amikor egy új Lambda függvényt adtunk hozzá az API átjárónkhoz, létrehoztunk egy auth módszert az átjárónkhoz. Ezt fogjuk használni a hitelesítéshez. Érdemes az Amazon API Gateway már meglévő funkcióira támaszkodni, beleértve a kérések érvényesítését is. Az API Gateway képes validálni a lekérdezési karakterláncot, a fejléceket és a testet. Ez utóbbit egy későbbi bejegyzésben tárgyaljuk, mert ehhez egy modell létrehozása szükséges. A lekérdezési karakterlánc paramétereinek beállítása sokkal egyszerűbb.

Adjuk meg a felhasználónevet és a jelszót URL-lekérdezési karakterlánc paraméterként, és jelöljük meg őket Kötelezőnek. A Request Validator alatt válasszuk a Validate query string parameters and headers lehetőséget.

Az AWS API Gateway mostantól ellenőrzi ezeket a paramétereket, és ha nem léteznek, az átjáró hibát jelez a felhasználónak.

Ne felejtsük el Deploy-olni (közzétenni) az API-t.

Szükséges engedélyek beállítása a Lambda számára

A Lambda függvényünknek hozzá kell férnie a Cognito felhasználói készletünkhöz. Igen, jól sejted, hogy az IAM-et fogjuk használni.

Nincs alapértelmezett házirend a kiadni kívánt engedélyekhez, ezért létrehozunk egy új házirendet. Szükségünk van az AdminInitiateAuth és az AdminSetUserPassword engedélyekre a Lambda függvényünkhöz, hogy kezelni tudjuk a Cognito felhasználói állományunkat.

A Házirendek alatt a „Házirend létrehozása”, a szolgáltatásoknál pedig a Cognito User Pools lehetőséget választjuk. A Művelet alatt kiválasztjuk a két engedélyt, az Erőforrások alatt pedig hozzáadjuk a Cognito User Pool ARN-jét.

Ezután létrehozzuk ezt a házirendet, és csatoljuk a simple-api-Role-hoz, ahogy azt az előző bejegyzésben megtanultuk.

Felhasználó megerősítése

Menjünk vissza a Lambdához, és szabaduljunk meg a bosszantó „FORCE_CHANGE_PASSWORD” állapottól. Ehhez írjunk egy egyszerű Lambda függvényt, amely megváltoztatja a felhasználó jelszavát.

Ezt a kódot használtam a felhasználó megerősítésére:

const params = {
    Password: 'password',
    UserPoolId: 'Pool Id',
    Username: 'username',
    Permanent: true
};
    
await cognito.adminSetUserPassword(params).promise();

Futtassa a kódot, és ha mindent helyesen állítottunk be, a Cognito azt fogja mutatni, hogy a számla státusza mostantól CONFIRMED (megerősített).

Utolsó simítások

Már majdnem kész vagyunk! Már csak egy kis kódot kell írnunk, amely a Cognitót hívja az engedélyezéshez. Szerencsére már van egy minta Lambda függvényünk, amit módosíthatunk: simple-api-auth

Cseréljük ki a korábbi kódot erre a minta kódra:

const aws = require('aws-sdk');
const cognito = new aws.CognitoIdentityServiceProvider();

exports.handler = async (event) => {
    const params = {
        AuthFlow: 'ADMIN_NO_SRP_AUTH',
        ClientId: 'App client id',
        UserPoolId: 'Pool Id',
        AuthParameters: {
            USERNAME: event.queryStringParameters.username,
            PASSWORD: event.queryStringParameters.password
        }
    };
    
    var authResponse = await cognito.adminInitiateAuth(params).promise();
    
    const response = {
        statusCode: 200,
        body: JSON.stringify(authResponse),
    };
    return response;
};

Deploy-ojuk (tegyük közzé) és kész is vagyunk!

API Gateway hitelesítés tesztelése

Menjünk a Postman-be, és nézzük meg, hogy minden az elvárásoknak megfelelően működik-e.

Ha meghívjuk a /hello metódusunkat, a következő hibát kapjuk:

„message”: „Unauthorized”

Nagyszerű! Szükségünk van egy IdTokenre a módszer eléréséhez. Hívjuk meg az auth metódusunkat, hogy megkapjuk a tokent. Az API Gateway ellenőrizni fogja, hogy megvan-e a felhasználónév és a jelszó paraméter. Ha nem, akkor hibát fogunk kapni.

Megkaptuk a token-ünket. Ha most visszamegyünk a /hello metódushoz és beállítjuk az Authorization fejlécet, akkor hozzáférünk a függvényhez. Ügyeljünk arra, hogy az IdToken-t használjuk az Authorization-hez.

És voilá! Az API átjárónk mostantól a Cognito-t használja hitelesítésre.

A API Gateway hozzáférés vezérlése Cognito-val bejegyzés először Road to AWS-én jelent meg.