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.

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.

Az AWS azt ajánlja, hogy a legtöbb feladathoz használjunk API-t, mivel később könnyebb lesz skálázni a felhőinfrastruktúrát. Ebben a példában egy egyszerű API-t hozunk létre, amely egy Lambda függvényt hív meg.

Javaslom, hogy egy beépített tervezettel kezdjünk, így az összes szükséges erőforrás automatikusan létrejön és összekapcsolásra került. Később módosíthatjuk ezeket a beállításokat.

Kezdés beépített tervezettel

Kezdjük az AWS Management Console-lal. Válasszuk ki a Lambda-t a szolgáltatások közül, és kattintsunk a Create function (Funkció létrehozása) gombra.

A Create function (Funkció létrehozása) alatt válasszuk a Use a blueprint (Tervezetek) lehetőséget, és a Blueprints (Tervezetek) alatt szűrjünk ki az „api” szóra. Válasszuk ki a microservice-http-endpoint blueprint-et, és kattintsunk a Configure (Konfigurálás) gombra.

A következő képernyőn konfiguráljuk a Lambda és az API átjárót. A Function name alatt adjunk nevet a függvénynek, a Role name alatt pedig állítsunk be egy szerepkört. Az API Gateway trigger alatt válasszuk a Create an API-t, és válasszuk a REST API-t API-típusként. Az AWS a HTTP API-t ajánlja a teljesítménye miatt, de jelenleg a REST API több funkcióval rendelkezik. A HTTP és a REST API teljes összehasonlítását ezen az oldalon tekinthető meg:
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html
Biztonsági okokból az API-kulcsot a Biztonság menüpont alatt választjuk ki. Egy későbbi szakaszban ezt Cognito-ra fogjuk változtatni, de egyelőre az API-kulcsok a legjobb megoldás, mert nagyon könnyen kezelhetőek és alapvető biztonságot nyújtanak.

A Lambda és az API-átjáró létrejött és összekapcsolódott. Nagyszerű munka!

Az API átjáró beállítása

Először kezdjük el az API átjáró konfigurálását. Válasszuk ki az AWS Management Console szolgáltatásai közül az API Gateway-t, majd az újonnan létrehozott API-t. Az API most már aktív és nyitott: bármilyen kapcsolatot elfogad, és nem igényel API-kulcsot. Mivel erre először nincs szükségünk, töröljük a GET metódust a minta API-nk alatt.

Hozzunk létre egy „hello” nevű erőforrást. Válasszuk ki az API gyökerét (esetünkben a simple-api-t), majd a Műveletek menüpontban válasszuk a Create Resource lehetőséget. Nevezzük el az erőforrásunkat „hello” névvel.

Ezen erőforrás alatt létrehozunk egy GET metódust. Mindenképpen jelöljük be a „Use Lambda Proxy Integration” opciót, mert így fogjuk beolvasni az erőforrás nevét a Lambda-ból. Továbbá válasszuk ki a Lambda Function-t, amelyet a beépített tervezet automatikusan létrehozott.

Most pedig alkalmazzunk némi biztonságot az API-nkra. Válasszuk ki az újonnan létrehozott GET metódust, és kattintsunk a Method Request gombra. Itt változtassuk meg az API Key Required értékét true-ra (igazra).

Már majdnem készen vagyunk az API átjáró konfigurációjával! De most jön a legfontosabb rész. Közzé tennünk az API-t. Az Action menüpont alatt válasszuk a Deploy API lehetőséget.
Mielőtt továbblépnénk, írjunk le néhány fontos információt: az Invoke URL-ünket és az API kulcsunkat. A Stages alatt válasszuk ki az alapértelmezett stage-et, ahol az invoke URL-t találjuk. Az API Keys alatt találjuk a simple-api-Key-t, ami az API kulcsunk. Most már visszamehetünk a Lambdához.

Configuring Lambda

A tervezet létrehozott egy Dynamo DB példát. Egyelőre nem fogjuk használni a Dynamo DB-t. Cseréljük ki az alapértelmezett kódot erre. És kattintsunk a Deploy gombra. Most már tesztelhetjük az API-nkat!

const AWS = require('aws-sdk');

exports.handler = async (event, context) => {
    
    var response_status, response_body; 
    
    if (event.resource.endsWith('hello')) {
        response_status = 200;
        response_body = "Hello from Lambda";
    }
    else {
        response_status = 200;
        response_body = "Unsupported resource";
    }

    const response = {
        statusCode: response_status,
        body: JSON.stringify(response_body),
    };
    return response;
};

Az API-k tesztelésére a legjobb eszköz a Postman. Ingyenesen létrehozhunk egy fiókot.

A postmanben teszteljük az újonnan elkészített API-t. Ügyeljjünk arra, hogy beállítsuk az API-kulcsot.

Szép munka! Most már van egy teljesen működő API-nk alapvető biztonsággal.

A Egyszerű API átjáró létrehozása AWS-en bejegyzés először Road to AWS-én jelent meg.