CookiesManager est un simple gem qui facilite le stockage de tous types d'objets dans les cookies (strings, tableaux, hashes, etc...). Utile pour y stocker par exemple des préférences d'utilisateurs à caractère non-confidentiel.
Ceux qui ont déjà essayé de stocker des tableaux ou des hashes dans des cookies ont dû se rendre compte qu'il faut sérialiser ces objets avant de pouvoir les stocker, puis les désérialiser à chaque fois qu'on veut les lire, et parfois refaire cela plusieurs fois, ce qui n'améliore pas les perfs de votre appli.
J'ai donc créé ce petit gem qui gère automatiquement les sérialisations et désérialisations des objets dans vos cookies, avec un cache en mémoire qui évite de désérialiser plusieurs fois les mêmes données pendant le traitement d'une requête HTTP. En bonus, je me suis aussi amusé à le rendre threadsafe et à tester les sections critiques avec de l'AOP, ce qui fut un petit régal.
Publié aujourd'hui, ce gem a été testé avec RSpec 2 sous ruby 1.8.7 et rails 2.3.14. Il reste encore à le faire marcher sous ruby 1.9.3 et rails 3, donc j'encourage tout le monde à contribuer à l'évolution de ce gem. Attention tout de même à ne pas abuser des cookies, car ca fait grossir les headers HTTP (en plus de nos femmes) !
1ere vanne sur http://rubylive.fr, bravo ! :p
Il y a plus de 12 ansC'est une idée sympa, mais malheureusement très dangereuse d'un point de vue sécurité: l'utilisateur peut mettre n'importe quoi dans un cookie, et n'importe quel objet pourrait ainsi être désérialisé et exécuter du code. Il ne faut jamais faire confiance à ce qui vient du côté client :)
Il y a plus de 12 ansSi tu veux vraiment stocker un objet sérialisé en lien avec un cookie, stocke-le dans une table à part, indexée par un hash (pour le rendre impossible à prédire), et mets le hash dans le cookie.
@Camille : ;-)
Il y a plus de 12 ans@Geoffroy : Très bonne remarque sur la sécurité. Effectivement, un utilisateur peu scrupuleux peut facilement injecter du code néfaste qui pourait être exécuté au moment où le serveur appelle les propriétés de ces objets (dans le cas des arrays ou hashes, il peut surcharger et corrompre par exemple les méthodes each et []). Mais heureusement qu'il existe des solutions à ce type d'attaque, comme le chiffrement ou bien la vérification de l'intégrité des données que j'essayerai de suggérer dans le README comme pistes d'améliorations possibles. Dans l'absolu, c'est vrai c'est plus sûr de stocker dans le cookie uniquement un petit id pointant vers un objet persisté en base, et c'est ce qui se fait souvent. Mais cela nécessite alors un aller-retour entre la base et le serveur, et une lecture dans une table (qui peut grossir), ce qui peut parfois prendre plus de temps que de directement lire son petit tableau de strings depuis le cookie. Le choix dépend donc beaucoup de la taille de ton appli et de l'infra, et de ce que tu comptes stocker. :-)
le problème, c'est que le chiffrement et les MAC, peu de développeurs savent s'en servir correctement. Pour l'appel à la base, c'est pas censé être énorme, car le hash n'a pas besoin d'être très long, et on peut nettoyer la table régulièrement.
Il y a plus de 12 ansJe ne pense pas que l'économie d'un appel à la BDD justifie le risque, là.
Sauf que si tes données sont des préférences utilisateurs qui doivent persister longtemps, tu ne peux pas faire le ménage trop souvent dans ta table. Du coup, si t'as beaucoup d'utilisateurs, ta table va grossir et tes requêtes peuvent prendre du temps même si c'est bien indexé.
Il y a plus de 12 ansLe but est d'éviter de faire appel à la base quand on peut s'en passer. Le but n'est pas non plus d'inciter les gens à stocker des objets au sens propre dans les cookies, ce qui serait évidemment une mauvaise recommandation. Je veux seulement pouvoir stocker mes petits tableaux quand ça peut être pratique. Le chiffrement des données, si on décide le mettre en place, ne demanderait que peu d'effort au développeur à part le setup d'une clé secrete, puisque tout le mécanisme de cryptographie serait géré automatiquement au sein du gem. Mais avant même de parler de chiffrement, je crois qu'il est possible depuis Ruby 1.9.x de caster une structure de données en hash ou en array, ce qui annulerait le risque d'exécuter du code objet dangereux. Je me demande si les méthodes "try_convert" des classes Array ou Hash ne pourraient pas nous aider ? :-/