In het kort: Wanneer je cookiegrootte de 4KB browserlimiet overschrijdt, splits het dan in meerdere kleinere cookies en reconstrueer ze aan de serverzijde. Deze oplossing werkt vooral goed voor serverloze platforms zonder dat er extra infrastructuur nodig is.
Cookiegebruik in Logto SDK's#
In de meeste Logto SDK's voor traditionele webapps slaan we sessiegegevens op in HTTP-only cookies voor de beveiliging. Dit is onze aanpak:
Wanneer de SDK acties uitvoert die sessiegegevens vereisen, dan:
- Versleutelt deze met symmetrische encryptie
- Slaat de versleutelde string op in een HTTP-only cookie
- Stelt beveiligde vlaggen in om alleen HTTPS-transmissie te garanderen
Deze aanpak vereist geen externe opslag en kan direct worden ingezet op populaire serverloze platforms zoals Vercel zonder enige veranderingen aan de infrastructuur.
Het probleem: Overschreden cookiegrootte fout#
Echter, bij het implementeren van multi-organisatiesupport, stuitten we op een beperking. Onze cookiegrootte groeide voorbij de 4KB browserlimiet omdat we moesten opslaan:
- Aanmeld- en andere sessiegegevens
- ID-tokens voor gebruikersauthenticatie
- Vernieuwtokens
- Toegangstokens met verschillende bronindicatoren
- Organisatietokens die in JWT zijn met payload, één per organisatie, wat vrij groot kan zijn als meerdere organisaties tegelijk actief zijn
Dit resulteerde in de foutmelding:
Browsers hanteren strikte beperkingen voor cookiegrootte, waarbij de meeste individuele cookies tot 4KB beperken en de totale cookiegrootte tot 8KB per domein.
Wat met externe opslag?#
Het gebruik van externe opslag zoals Redis of een database zou extra opzet van infrastructuur vereisen, wat zowel de kosten als de complexiteit voor SDK-gebruikers verhoogt. Dit gaat tegen ons doel in om een ontwikkelaarsvriendelijke oplossing te bieden.
Hoewel in-memory opslag een alternatief zou kunnen zijn, werkt het niet goed voor serverloze omgevingen waarbij instanties vluchtig zijn en geheugen niet wordt gedeeld tussen aanvragen.
De oplossing: Cookies splitsen#
Een eenvoudige oplossing is om grote cookies in kleinere stukjes te splitsen. Dit artikel toont de aanpak met Next.js als voorbeeld:
1. Splits de sessiegegevens#
2. Sla de stukken op#
3. Herbouw bij aanvraag#
Best practices voor implementatie#
1. Stukgroottebeheer#
2. Schoon sessiebeheer#
Monitor totale cookiegrootte:#
Conclusie#
Cookies splitsen biedt een elegante oplossing die zowel makkelijk te implementeren is als minimaal verstorend is voor de bestaande applicatie-architectuur. Door simpelweg grote cookies in kleinere stukjes te breken, kunnen ontwikkelaars de beperkingen van de browseromvang overwinnen zonder hun kernsessiebeheerbenadering te wijzigen of externe afhankelijkheden toe te voegen.
