Egy beágyazott chat, térkép vagy fizetési widget sokszor nem kér globális bejelentkezést; csak azt kell megjegyeznie, hogy az adott oldalon melyik beszélgetés, konfiguráció vagy terheléselosztó-változat tartozik a látogatóhoz. A hagyományos harmadik féltől származó cookie ennél többet tud: ugyanazt az azonosítót elküldheti minden, a widgetet beágyazó oldalról. Ez követésre is alkalmas, ezért a böngészők egyre szigorúbban kezelik.
Erre való a CHIPS (Cookies Having Independent Partitioned State) és a Partitioned cookie-attribútum. Nem a harmadik fél cookie-ját teszi újra korlátlanul használhatóvá, hanem két kulccsal tárolja: a cookie-t kibocsátó hostja mellett a felső szintű oldal schemeful site-ja is a kulcs része. Ugyanaz a widget.example iframe így külön cookie-t kap a bolt-a.hu és a bolt-b.hu alatt.
Mit old meg, és mit nem?
Ez jó választás, ha a beágyazott szolgáltatásnak helyi, nem érzékeny állapot kell: egy ügyfélszolgálati panel nyitott beszélgetése, egy térkép nézetállapota vagy egy CDN-nek szóló, webhelyenként elkülönülő routingjelzés. A cookie továbbra is elküldhető a widget saját szerverének, amikor az iframe az adott oldalon fut; a bolt-a.hu-hoz létrejött érték viszont nem bukkan fel bolt-b.hu alatt.
Ezért nem SSO-megoldás. Ha egy identitásszolgáltató iframe-je minden ügyféloldalon ugyanazt a bejelentkezett felhasználót akarja felismerni, éppen az egységes, partíció nélküli állapot hiányzik. Ilyen esetben a Storage Access API kérhet hozzáférést a korlátozott harmadik feles, nem partícionált tárolóhoz; ehhez felhasználói interakció és böngészőfüggő engedélyezés is tartozhat. A CHIPS-et ne ezzel próbáljuk kiváltani.
Egy használható Set-Cookie fejléc
Egy cross-site iframe-ben futó widget cookie-ja például lehet ilyen:
import http from 'node:http';
const server = http.createServer((request, response) => {
if (request.url !== '/frame') return response.writeHead(404).end();
response.setHeader(
'Set-Cookie',
'__Host-widget_state=8c1f; Path=/; Max-Age=1800; ' +
'SameSite=None; Secure; HttpOnly; Partitioned',
);
response.end('<p>Beágyazott widget</p>');
});A Partitioned kötelező társa a Secure: a böngésző csak biztonságos kontextusban fogadja el. A cross-site iframe-es használathoz a SameSite=None is kell, különben a SameSite-szabályok miatt a kérés nem viszi a cookie-t. A Set-Cookie dokumentáció szerint a __Host- prefixhez Secure, Path=/ és Domain nélküli fejléc szükséges. Ez szándékosan hostra szűkíti a cookie-t, ezért widgetnél biztonságos alapértelmezés, ha nem kell aldomainnel megosztani.
A példában az HttpOnly azt jelenti, hogy a JavaScript nem olvashatja ki az értéket. Állapotot ettől még a böngésző elküld a szervernek. Az időkorlát sem dísz: a Max-Age legyen a funkcióhoz szükséges legrövidebb érték, és ne kerüljön ide felhasználói session vagy tartós, webhelyek közötti azonosító.
Nem felhasználóazonosító
Az azonos cookie-név és -érték több partícióban is létezhet. Emiatt a __Host-widget_state nem alkalmas arra, hogy a widget szolgáltatója ebből számolja az egyedi felhasználókat, vagy ebből vezesse le a központi jogosultságot. Egy látogató egy új beágyazó oldalon új, üres állapotot kap; ez a tulajdonság, nem hiba. A szerveroldalon is úgy tervezzünk, hogy a cookie egy adott beágyazás állapota, nem a böngésző univerzális identitása.
Ez adatmodellezési döntés is. A widgetnek saját, top-level oldaltól független fiókja lehet, de a partícionált cookie-ban csak egy rövid élettartamú, az adott integrációra érvényes referencia legyen. Ha a felhasználó tényleg azonosítani akarja magát, azt látható, első féltől induló beléptetési folyamattal vagy erre való federált megoldással érdemes kezelni.
A félrevezető teszt
A fejlesztői gépen könnyű úgy ellenőrizni, hogy közvetlenül megnyitjuk a widget saját domainjét. Ezzel viszont más tárolópartíciót tesztelünk, mint amikor az iframe egy ügyféloldal alatt fut. Két külön top-level tesztoldal kell: töltsük be mindkettőbe a widgetet, állítsunk be eltérő állapotot, majd nézzük meg, hogy az első oldalra visszatérve csak a saját értéke marad-e meg. A modern DevTools cookie-nézetében a partíció kulcsa is segít ezt ellenőrizni.
A kompatibilitási döntést nem szabad pusztán attribútum-felismerésre építeni. A böngészőtámogatási táblázat mellett azt is tesztelni kell, mit csinál a szolgáltatás akkor, ha nincs megőrizhető harmadik feles állapot. Egy chat esetén ez lehet új beszélgetés indítása; fizetésnél vagy beléptetésnél viszont jellemzően más integrációs terv kell.