En bref : Lorsque la taille de votre cookie dépasse la limite de 4 Ko du navigateur, divisez-le en plusieurs petits cookies et reconstruisez-les côté serveur. Cette solution fonctionne particulièrement bien pour les plateformes sans serveur sans nécessiter d'infrastructure supplémentaire.
Utilisation des cookies dans les SDK Logto#
Dans la plupart des SDK Logto pour les applications web traditionnelles, nous stockons les données de session dans des cookies HTTP-only pour des raisons de sécurité. Voici notre approche :
Lorsque le SDK effectue des actions nécessitant des données de session, il :
- Crypte les données à l'aide d'un cryptage symétrique
- Stocke la chaîne cryptée dans un cookie HTTP-only
- Définit des drapeaux de sécurité pour assurer une transmission uniquement via HTTPS
Cette approche ne nécessite aucun stockage externe et peut être déployée directement sur des plateformes sans serveur populaires comme Vercel sans aucun changement d'infrastructure supplémentaire.
Le problème : erreur de taille de cookie dépassée#
Cependant, lorsque nous avons mis en place la prise en charge multi-organisationnelle, nous avons rencontré une limitation. La taille de notre cookie a dépassé la limite de 4 Ko du navigateur car nous devions stocker :
- Les données de connexion et autres données de session
- Les jetons d'identification pour l'authentification de l'utilisateur
- Les jetons de rafraîchissement
- Les jetons d'accès avec différents indicateurs de ressources
- Les jetons d'organisation qui sont en JWT avec charge utile, un par organisation, ce qui peut être assez volumineux dans le cas où plusieurs organisations sont actives en même temps
Cela a entraîné l'erreur :
Les navigateurs imposent des limites strictes à la taille des cookies, la plupart limitant les cookies individuels à 4 Ko et la taille totale des cookies à 8 Ko par domaine.
Qu'en est-il de l'utilisation d'un stockage externe ?#
L'utilisation d'un stockage externe comme Redis ou une base de données nécessiterait la mise en place d'une infrastructure supplémentaire, augmentant à la fois les coûts et la complexité pour les utilisateurs du SDK. Cela va à l'encontre de notre objectif de fournir une solution conviviale pour les développeurs.
Bien que le stockage en mémoire puisse être une alternative, il ne fonctionne pas bien dans les environnements sans serveur où les instances sont éphémères et la mémoire n'est pas partagée entre les requêtes.
La solution : la division des cookies#
Une solution simple est de diviser les cookies volumineux en petits morceaux. Cet article démontre l'approche en utilisant Next.js comme exemple :
1. Diviser les données de session#
2. Stocker les morceaux#
3. Reconstruire sur demande#
Meilleures pratiques pour l'implémentation#
1. Gestion de la taille des morceaux#
2. Gestion propre des sessions#
Surveiller la taille totale des cookies :#
Conclusion#
La division des cookies offre une solution élégante qui est à la fois facile à mettre en œuvre et très peu perturbatrice pour l'architecture existante des applications. En divisant simplement les cookies volumineux en plus petits morceaux, les développeurs peuvent surmonter les limitations de taille des navigateurs sans changer leur approche de gestion de session principale ou ajouter des dépendances externes.
