Projektjeinkre, a biztonságra és az adatszuverenitásra szabott hozzájárulási architektúra
Webalkalmazásainkhoz a hozzájárulások kezelését magunk építettük meg, ahelyett hogy külső consent-platformra bíztuk volna. A működést, a megjelenést és a viselkedést mi határozzuk meg; a hozzájárulások és naplóik a saját infrastruktúránkon maradnak – idegen szkript nélkül a betöltési útvonalon és folyamatos díjak nélkül.
- Típus
- Technikai esettanulmány
- Modul
- @woop-technology/
consent - Referenciaprojektek
- Woop Art
- Ez a weboldal
- Állapot
- Használatban | folyamatos fejlesztés alatt
- Integráció
- React | Next.js App Router
- Kiszolgálás
- Privát csomagkezelés
- Hozzájárulási architektúra
- Adatszuverenitás
- Google Consent Mode v2
- Cookie-nyilvántartás
- verziózott hozzájárulások
- szkriptszűrés
- cserélhető adatforrások
- többnyelvűség
- projektenkénti felületek
- szerveroldali naplózás
Miért fejlesztettük ki saját hozzájárulás-kezelésünket
A webalkalmazások gyakran építenek be külső szolgáltatásokat, például analitikát, térképeket, videókat vagy időpontfoglalást. Ezzel további adatáramlások jönnek létre – és két kérdés: milyen feltételekkel tölthetők be ezek a szolgáltatások, és mi történik az adatokkal, miután elhagyták a saját szerverünket.
A kézenfekvő válasz egy külső consent-platform lenne. Számunkra három olyan dolgot hozott volna, amit nem akartunk: még egy havi számlát, egy hozzájárulási rendszert, amely csak addig ér be az alkalmazásba, ameddig a szolgáltató engedi – és látogatóink hozzájárulási adatait idegen szervereken.
Ezért fejlesztettük ki saját hozzájárulás-kezelésünket: alkalmazásarchitektúránk szerves részeként, újrafelhasználhatóan és testreszabhatóan – és úgy, hogy az adatok kizárólag a saját infrastruktúránkon maradjanak.
- 01A hozzájárulások és tárolt értékek központi kezelése, külső szolgáltató nélkül
- 02Szolgáltatások hozzájárulástól függő engedélyezése
- 03A hozzájárulások és naplók feldolgozása kizárólag saját infrastruktúrán
- 04Különböző nyelvek, adatforrások és felületek támogatása
- 05Újrafelhasználható legyen, havi vagy projektenkénti többletdíj nélkül
Ebből jött létre az önálló hozzájárulás-motor, amelyet ma közös technikai modulként használunk projektjeinkben.
Három dolog, amit nem adunk ki a kezünkből
Egy külső consent-platform egy további szolgáltatót hoz magával: saját szkripteket, saját konfigurációt, saját szervereket és folyamatos díjat. Saját motorunk ezzel szemben az alkalmazással együtt fut, ugyanazon az infrastruktúrán belül és ugyanazokkal az eszközökkel.
Hogy ez a gyakorlatban mit jelent, három pontban foglalható össze.
- Költségek
- Nincs licenc domainenként, oldalmegtekintésenként vagy havonta. A költségek egyszer, a fejlesztéskor, majd folyamatosan a karbantartásban merülnek fel.Ez azért fenntartható, mert ugyanaz az építőelem több projektben fut.
- Kontroll
- A működést, az adatalapot, a megjelenést és a viselkedést mi határozzuk meg – egészen az alkalmazáskódig, amely közvetlenül lekérdezheti a hozzájárulási állapotot.Semmi sem ér véget ott, ahol egy szolgáltató kínálata véget ér.
- Adatok
- A konfiguráció, a hozzájárulások és a naplók saját szervereinken vannak. Harmadik fél nem tárolja, nem dolgozza fel és nem látja a látogatók döntéseit.
A hozzájárulási funkcióhoz nem szükséges külső CMP
A hozzájárulási konfiguráció és a központi motor a saját alkalmazás része. Magához a hozzájárulási rendszerhez ezért nincs szükség külső CMP‑szolgáltatóra.
- nincs további CMP-szkript
- nincs külső hálózati hívás magához a hozzájárulási funkcióhoz
- nincs idegen hozzájárulási felület
- nincs további platformfüggőség pusztán a hozzájárulások kezelése miatt
A hozzájáruláshoz kötött szolgáltatások ettől elkülönülnek, és csak akkor töltődnek be, ha a szükséges hozzájárulás rendelkezésre áll.
Kevesebb idegen kód, kisebb támadási felület
Egy külső consent-szkript ugyanazokkal a jogokkal fut, mint maga az oldal, és idegen szerverről töltődik be. A szolgáltató által kiadott minden verzió így a weboldal részévé válik anélkül, hogy részleteiben ellenőrizhető lenne.
Bevált szolgáltatóknál ez általában nem jelent problémát. Mi mégis szívesebben ismerjük a kódot, amely az oldalainkon fut: saját motorunkat az alkalmazás többi kódjához hasonlóan verziózzuk, ellenőrizzük és telepítjük.
- csak a saját eredetről érkező kéréseket fogadja el
- minden kérést ellenőriz, hogy teljes és megengedett mezőket tartalmaz-e
- a mentés előtt rövidíti az IP-címet
- rögzített útvonalon található, amelyhez az elé kapcsolt tűzfal saját szabályokat tarthat
A hozzájárulások és naplók saját szervereinken vannak
A hozzájárulások kezelésében nem vesz részt további szolgáltató. A látogató döntése az alkalmazásban lép érvénybe, és ugyanazon a szerveren kerül naplózásra, amelyen az alkalmazás fut – ott, ahol a projekt többi adatát is feldolgozzuk. Ez minden projektre igaz, amely a motort használja: a döntéseket helyben, az adott alkalmazás konténerében naplózzuk.
Azt, hogy egy konkrét projekt milyen további külső szolgáltatásokat használ, és eközben milyen adatok kerülnek továbbításra, ettől függetlenül, projektenként határozzuk meg és dokumentáljuk.
Három elkülönített réteg a logikának, az adatoknak és a megjelenítésnek
A hozzájárulási rendszer elválasztja a központi működési logikát a projektspecifikus adatoktól és a látható felülettől.
Így ugyanaz a technikai alap különböző alkalmazásokban is használható anélkül, hogy a hozzájárulási állapotot, a verziózást vagy a szkriptszűrést minden projektben újra kellene implementálni.
A modul szabványos felületet hoz magával, amelyet a projekt átalakít vagy teljesen lecserél. Így ugyanaz a motor fut egy művészeti platformon és egy vállalati weboldalon, noha a két felület megjelenése eltér.
- Hozzájárulás-motor
- A központi motor látja el azokat a funkciókat, amelyek projekteken átívelően azonosak:
- hozzájárulási állapot
- verzióellenőrzés
- cookie-nyilvántartás
- szkriptszűrés
- kétkattintásos megoldások
- visszavonás
- a bejelentett tárolási értékek törlése
- Google Consent Mode v2
- Adatforrás
- A motor a projektspecifikus információkat egy meghatározott interfészen keresztül kapja meg. Ide tartozik többek között:
- hozzájárulási verzió
- kategóriák és szolgáltatások
- cookie-k és további tárolási értékek
- nyelvenkénti szövegek
- szkriptkonfigurációk
- Felület
- A sávot és a beállítási ablakot az adott projekthez tervezzük. A felület a szükséges adatokat és a rögzített műveleteket a központi motortól kapja.Így a vizuális megjelenés projektenként igazítható anélkül, hogy a mögöttes hozzájárulási logikát módosítani kellene.
Minden a saját infrastruktúránkon.
A referenciaprojektek alatti számok az adott konfigurációra vonatkoznak. A kategóriák, szolgáltatások és cookie-k szabadon konfigurálhatók.
Közös modul projektenkénti egyedi megoldások helyett
A hozzájárulás-motort a Woop Technology privát csomagtárán keresztül, önálló csomagként biztosítjuk. A verziókat és a változtatásokat központilag kezeljük; minden projekt a számára szükséges verziót építi be, és a frissítéseket saját ütemében veszi át – így különböző projektek egyidejűleg különböző verziókat futtathatnak.
Minden új projekt négy területet egészít ki:
- 01Adatok
- Kategóriák, szolgáltatások, tárolási értékek és szövegek.
- 02Perzisztencia
- Hová kerülnek a hozzájárulási döntések naplói.
- 03Integrációk
- Analitika és más, hozzájáruláshoz kötött szolgáltatások.
- 04Design
- Alapértelmezett felület vagy egyedi sáv- és beállításkomponensek.
A hozzájárulási állapot, a verziózás, a nyilvántartás, a szkriptszűrés és a visszavonás a közös modulból származik. A motor fejlesztései verziózott frissítésekkel több projektbe is átvihetők.
Amit a motor hoz, amit a projekt dönt el
- 01Motorkategóriaalapú hozzájárulás, verziózás, visszavonás, cookie-tisztítás, szkript-gating, Google Consent Mode v2
- 02Projektadatforrás (JSON, API vagy headless CMS), nyelvek, felület (szabványos UI vagy saját komponensek), integrációk (hookok, kétkattintásos megoldások)
- 03Perzisztenciahozzájárulási cookie a böngészőben, szerveroldali naplózás, rövidített IP-címek
- 04Stack & üzemeltetésReact, TypeScript, Next.js App Router, dependency injection, privát csomagtár, ellenőrzött bemenetek
A hozzájáruláshoz kötött szolgáltatások csak a hozzájárulás után töltődnek be
Központi elvárás volt, hogy a hozzájáruláshoz kötött szolgáltatások a hozzájárulás előtt ne csupán kikapcsolt állapotban legyenek. Egyáltalán ne töltődjenek be.
Ehhez több mechanizmus kapcsolódik össze.
- A Consent Mode elutasított állapotból indul
- A Google Consent Mode v2 az első oldalbetöltéskor a megfelelő elutasított tárolási állapotokkal inicializálódik. Ha érvényes döntés áll rendelkezésre, vagy megszületik a hozzájárulás, ez az állapot célzottan frissíthető.
- Hozzájárulás nélkül nincs hozzájáruláshoz kötött szkript
- A motor csak azokat az integrációkat bocsátja rendelkezésre, amelyek hozzájárulási kategóriáját ténylegesen elfogadták. A referenciaprojektben ez például azt jelenti: analitikai hozzájárulás nélkül nem épül be Google Analytics szkript.A döntés így nem az egyes komponensek között oszlik meg, hanem központilag, a hozzájárulási állapoton keresztül dől el.
A nyilvántartás összetartja a technikai használatot és a dokumentációt
Annak érdekében, hogy a bejelentett tárolási értékek és a tényleges implementáció ne egymástól függetlenül alakuljon, a motor központi nyilvántartást használ. A hozzájárulási infrastruktúrán keresztül kezelt minden tárolási értékhez technikai tulajdonságokat rögzítünk.
- azonosító
- cookie-név vagy névminta
- kapcsolódó szolgáltatás
- kategória
- tárolási idő
- tárolási mód
A nyelvfüggő adatokat – például a célt és a leírást – ettől elkülönítve tartjuk karban.
Ha az alkalmazáskód a hozzájárulási infrastruktúrán keresztül nem regisztrált értéket próbál írni, a művelet elutasításra kerül. A nyilvántartás így nemcsak dokumentáció, hanem a technikai kontroll része is.
A hozzájárulási döntések konfigurációs verzióhoz kötöttek
Minden hozzájárulási konfigurációnak van verziója.
- hozzájárulási azonosító
- a konfiguráció verziója
- a döntés időpontja
- az elfogadott kategóriák
Egy későbbi látogatáskor a motor összeveti a tárolt verziót az aktuálisan használttal. Ha a kettő eltér, a motor elveti a tárolt választást, és új döntést kér.
Egy újonnan hozzáadott szolgáltatás így új hozzájárulási verzióval kezelhető anélkül, hogy minden weboldalhoz külön migrációs logikát kellene fejleszteni.
A megváltoztatott döntés technikailag is érvényesül
A hozzájárulás a beállításokon keresztül bármikor módosítható. Ha egy korábban elfogadott kategóriát visszavonnak, nemcsak a tárolt hozzájárulási állapot változik meg.
- eltávolítja a visszavont kategória bejelentett tárolási értékeit
- frissíti a Google Consent Mode-ot
- megakadályozza a kapcsolódó szolgáltatások ismételt betöltését
- és szükség esetén újraépítéssel tiszta állapotba hozza az alkalmazást
Az újraépítés azért lényeges, mert a már lefutott harmadik féltől származó szkriptek nem vonhatók vissza megbízhatóan pusztán a szkriptelem eltávolításával.
A visszavonás után az állapotnak ezért olyannak kell lennie, mint egy olyan látogató esetében, aki az adott kategóriát soha nem engedélyezte.
Mit tárol egy hozzájárulás a böngészőben
Két kattintás, mielőtt egy külső szolgáltatás betöltődik
Nem minden hozzájárulás való a bannerbe. Beágyazott szolgáltatásoknál, például az időpontfoglalásnál, a motor ott kéri, ahol a látogató ténylegesen használni akarja a szolgáltatást.
- 01
Első kattintás: tájékoztatás
A gomb megmutatja, melyik szolgáltató töltődne be, és milyen adatok kerülnének továbbításra. A felirata „Google Naptár betöltése” lesz.
- 02
Második kattintás: betöltés
Csak ekkor kerül be a szolgáltató scriptje és stíluslapja, és nyílik meg a foglalás. Addig egyetlen kérés sem jut el a Google-höz.
- 03
A banner kerülőútja nélkül
A látogatónak ehhez nem kell egyetlen kategóriát sem engedélyeznie a hozzájárulási beállításokban. A döntés magánál a szolgáltatásnál születik, csak erre a szolgáltatásra.
A szükséges komponensek ugyanabban a csomagban vannak, mint a motor: Google Naptárhoz és Calendlyhez készen, további szolgáltatásokhoz egy közös alapkomponensen keresztül.
A hozzájárulási azonosító egy kattintással kéznél van
Minden döntés naplózásra kerül a szerveren, egyértelműen azonban csak a hozzájárulási azonosító alapján kereshető vissza. Egy külön komponens ezt az azonosítót a látogatók keze ügyébe adja.
Az azonosító a hozzájárulási cookie-ban van, ahol fejlesztői eszközök nélkül senki sem látja. Mégis ez az egyetlen egyértelmű út a szerveren lévő bejegyzéshez, mivel az IP-címet a rendszer csak csonkolva tárolja.
A komponens megjeleníti az azonosítót, és egy kattintással másolja. Kérdés, panasz vagy hozzáférési kérelem esetén a látogatók egyszerűen mellékelik, és a bejegyzés visszakérdezés nélkül megtalálható – időponttal, verzióval és a választással.
A komponens az adott weboldal adatkezelési tájékoztatójában található, és onnan közvetlenül a hozzájárulási beállításokhoz is elvezet.
Az Ön jelenlegi hozzájárulási azonosítója (Consent ID)
Ezt az egyedi azonosítót helyileg a böngészőjében tároljuk, és pszeudonimizált formában mentjük szerverünkön, hogy igazolni tudjuk az Ön adatvédelmi választását. Ha kérdése vagy panasza van a hozzájárulásával kapcsolatban, kérjük, küldje el nekünk ezt az azonosítót is – így egyértelműen megtaláljuk a hozzá tartozó igazolást.
Még nem történt választásA komponens előkészítve érkezik a hozzájárulási csomaggal. A bannerhez és a beállítási ablakhoz hasonlóan szabadon megtervezhető: a működés a csomagban marad, a megjelenésről a projekt dönt – itt ennek a weboldalnak a stílusában.
A hozzájárulási logika nem kötődik meghatározott adatforráshoz
A hozzájárulás-motor nem maga olvassa be az adatait, hanem egy meghatározott interfészen keresztül kapja őket. Hogy honnan származnak, azt az interfész implementációja dönti el – a motor ugyanaz marad.
- Alapértelmezés: fájlok a projektben
- A mellékelt implementáció verziózott JSON‑fájlokat olvas, amelyek a forráskóddal együtt kerülnek kiszállításra. A konfigurációhoz nincs szükség hálózati hívásra.
- Szerkesztői CMS
- Ha az interfészt egy headless CMS‑hez implementálják, a szerkesztőség ott gondozza a szövegeket, szolgáltatásokat és sütiket – a motor módosítása nélkül.
- Saját rendszer API‑n keresztül
- Ugyanígy egy saját CMS vagy központi szolgáltatás is csatlakoztatható az API‑ján keresztül – például hogy több alkalmazás hozzájárulási adatait közösen kezeljék.
A technikai definíció és a fordítások elkülönülnek
A cookie-neveket, azonosítókat, kategóriákat és tárolási időket egyszer definiáljuk. A banner és a beállítási ablak szövegei ezzel szemben minden nyelven elérhetők; a látogató a kiválasztott nyelven látja őket:
- kategórianevek és -leírások
- szolgáltatásinformációk és cookie-célok
- adattovábbításra vonatkozó információk
- sávszövegek és gombfeliratok
- képernyőolvasó-feliratok
Közös logika, eltérő felületek
A motor alapértelmezett felületet kínál, amely részben vagy egészében projektspecifikus komponensekkel helyettesíthető.
Egy projekt- változatlanul átveheti a sávot és a beállítási ablakot
- csak a sávot alakíthatja ki saját maga
- csak a beállítási ablakot cserélheti le
- mindkét felületet egyedileg valósíthatja meg
A hozzájárulási állapot, a verziózás és a visszavonás eközben központilag kezelt marad.
A döntések szerveroldali naplózása
Minden hozzájárulás és minden későbbi módosítás a böngészőben tárolt állapot mellett egy rekordot is létrehoz a szerveren. Ez a naplózás a folyamat kötelező része, nem opció.
Hogy a rekord hová kerül, itt is az interfész implementációja határozza meg: alapértelmezés szerint az alkalmazás fájlként menti a saját szerverén. Ugyanígy API‑n keresztül egy másik szolgáltatásnak is átadhatja, amely például adatbázisban kezeli.
- a hozzájárulási azonosítót
- a konfiguráció verzióját
- a meghozott választást
- az időpontot
- a user agentet
- a rövidített IP-címet
Az IPv4-címeket a második blokk után, az IPv6-címeket a harmadik szegmens után rövidítjük. A beérkező bejegyzéseket ellenőrizzük; a hiányos vagy nem megengedett kéréseket elutasítjuk.
A naplózás támogatja a döntések nyomon követhetőségét, de nem jelent revízióbiztos archiválást.
A naplózás hibája nem blokkolja az alkalmazást
A látogató döntése először az alkalmazás hozzájárulási állapotában lép érvénybe. Ha a szerveroldali mentés meghiúsul, a weboldal továbbra is használható marad.
A hiba szerveroldalon kerül naplózásra ahelyett, hogy technikai részletek jelennének meg a böngészőben. A hozzájárulási rendszer működőképessége így nem függ attól, hogy a naplózás minden pillanatban elérhető-e.
A kattintástól a naplóbejegyzésig
01 Beállítások betöltve02 Választás fogadva03 Hozzájárulási állapot frissítve04 Döntés naplózvaFolyamat befejezve- 01
Választás a bannerben
A látogató kategóriánként dönti el, mely szolgáltatásokat engedélyezi. A szükséges tárolási értékek aktívak maradnak.
- 02
Végrehajtás az alkalmazásban
A motor elmenti a választást, frissíti a Google Consent Mode-ot, és engedélyezi a jóváhagyott szolgáltatásokat.
- 03
Naplózás a szerveren
A döntést a verzióval és az időponttal együtt naplózzuk.
Miért volt számunkra kézenfekvő a saját megoldás
A cél az volt, hogy függőségek és folyamatos költségek ki se alakuljanak. Hogy ezt gyorsan és megbízhatóan el tudtuk érni, annak köszönhető, amit már magunkkal hoztunk.
- Szakértelem az adatvédelemben és a hozzájárulás-kezelésben
- Hogy a hozzájárulások, a Google Consent Mode és a látogatók felé fennálló tájékoztatási kötelezettségek hogyan kapcsolódnak össze, az webalkalmazásokon végzett mindennapi munkánk része.
- Saját alkalmazások, nem weboldalépítő
- Projektjeink önálló webalkalmazások. A hozzájárulás-kezelést ezért az alkalmazás részeként lehetett felépíteni, ahelyett hogy kívülről csatolnánk hozzá.
- Saját infrastruktúra
- A tárhelyet, a telepítést és a tűzfalat magunk üzemeltetjük. A naplók saját szervereken tartásához ezért nem kellett új szolgáltatás, csak egy további végpont a meglévő alkalmazásban.
- Közös modulok
- Projektjeink privát csomagtárunkon keresztül már más modulokat is megosztanak. A hozzájárulás-motor ezek egyike, és minden új projekt számára elérhető.
A hozzájárulás-motor így nem volt nagy vállalkozás, hanem annak kiterjesztése, ami már megvolt.
A hozzájárulás közvetlenül beépíthető az alkalmazásba
A központi hozzájárulási állapot az alkalmazáskód számára is elérhető.
- Engedélyezett-e az analitika?
- Betölthető-e egy beágyazott videó?
- Szükséges-e hozzájárulás egy külső térkép előtt?
- Érvényes-e még a tárolt döntés az aktuális hozzájárulási verzióhoz?
A hozzájárulás így nem korlátozódik a sávra és a beállítási ablakra, hanem közvetlenül beépíthető az alkalmazás folyamatába.
A teljes kontroll teljes felelősséggel jár
Ahol nincs szolgáltató, ott senki sem frissíti a cookie-listákat, nem követi a Google Consent Mode változásait, és nem igazítja a szövegeket az új jogszabályokhoz. Ez a munka ránk hárul – az alkalmazásainkhoz amúgy is nyújtott karbantartás részeként –, vagy az ügyfélre, ha a szövegeket és adatokat egy csatlakoztatott CMS‑ben gondozzák.
Saját alap a hozzájárulás-kezeléshez, közbeiktatott szolgáltató nélkül
A hozzájárulás-motor ma különböző webalkalmazásokban működik – külső szolgáltató és folyamatos licenc nélkül, a hozzájárulásokkal és naplókkal a saját infrastruktúránkon. A központi funkciókat egyszer tartjuk karban, míg az adatok, integrációk, nyelvek és a felület projektenként maradnak.
- Függetlenség
- Nincs szolgáltató, nincs licenc, nincs idegen szkript a betöltési útvonalon.
- Adatszuverenitás
- A konfiguráció, a hozzájárulások és a naplók saját infrastruktúránkon vannak.
- Hozzájárulás a kötött szolgáltatások előtt
- A vonatkozó integrációk csak a szükséges hozzájárulás után töltődnek be.
- Verziózott döntések
- A tárolt hozzájárulások a hozzájárulási konfiguráció adott állapotához kötöttek.
- Központi hozzájárulási logika
- Az állapot, a verziózás, a nyilvántartás, a szkriptszűrés és a visszavonás közösen kezelt.
- Újrafelhasználható és rugalmas
- Adatforrások, nyelvek és felületek projektenként; a motor fejlesztései verziózott frissítésekkel.
Szeretné saját maga eldönteni, hová kerülnek látogatói adatai?
Az első beszélgetésen tisztázzuk, mely szolgáltatások továbbítanak adatokat harmadik feleknek az Ön weboldaláról, hol érdemes adattakarékos alternatívát választani, és hogyan maradhatnak a hozzájárulások és a naplók ott, ahol az alkalmazása fut.