Contourner la limitation du nombre de cookies pour un domaine dans un navigateur

[hp_angel]

Bonsoir à tous,

Je suis confrontée au problème suivant : dans un site e-commerce, la fonctionnalité de sauvegarde du panier est gérée à la fois en base de données, et également par cookies.
Intéressons-nous de plus près au fonctionnement par cookie : pour chaque article, on crée un cookie contenant sa référence (id), sa sous-référence (le modèle), le nombre d'articles choisis ainsi que des données de personnalisation (mon panier est géré sous format de tableau ce qui donne en gros : $_COOKIE['panier'][id][modèle][données]=quantité).

Le problème, c'est qu'en procédant ainsi, dès que l'on atteint 50 articles dans le panier, le 51ème article "efface" le cookie le plus ancien existant pour écrire son propre cookie (ce phénomène est notamment observé sous IE qui est limité à 50 cookies par domaine).

Il faut donc repenser le système existant... Sachant que la taille d'un cookie est limitée à 4 ko, soit 4096 caractères, et que chaque données pour un produit peut aller jusqu'à 140 caractères... ça me donnerait minimum 30 produits par cookie ? Comment gérer le découpage du cookie ?

Toute aide est la bienvenue, car là j'avoue ne pas trop savoir comment m'y prendre pour revoir le système.

Merci d'avance !

 

[JanoLapin]

ça me paraît vraiment beaucoup, un panier avec 50 articles différents (pas les quantités !). Ca t'arrive souvent?

 

[zeb]

Comment gérer le découpage du cookie ?

Ne pas le gérer, 1 cookies avec ID de panier et le contenu du panier en base ou autre ...

 

[hp_angel]

ça me paraît vraiment beaucoup, un panier avec 50 articles différents (pas les quantités !). Ca t'arrive souvent?

Là le problème m'arrive, c'est pour ça que j'ai remarqué le problème... comme il s'agit de petites fournitures, dès qu'un professionnel fait un approvisionnement, le nombre d'articles différents augmente rapidement.

 

[hp_angel]

Comment gérer le découpage du cookie ?

Ne pas le gérer, 1 cookies avec ID de panier et le contenu du panier en base ou autre ...

C'est ce que je pense le plus viable, après par contre je vais devoir remanier mon Ajax pour qu'à chaque modification dans le panier, la base de données soit mise à jour... ça me fait un peu peur au niveau de la charge potentielle que cela peut engendrer...

 

[zeb]

à chaque modification dans le panier, la base de données soit mise à jour

Si tu regarde bien le comportement de l'utilisateur en terme d'action, tu va avoir au pire une requête SQL par action panier et si tu compare cela a la navigation sur le site la fréquence sera surement moindre pour les actions panier que la navigation. Donc une requête face a N requêtes ... ça devrait largement tenir le coup.

 

[zeb]

Question subsidiaire, travaillerai tu sur ton propre logiciel d'e-commerce ou tu bidouille de l'existant open source ?

 

[hp_angel]

Pour les requêtes, je vais faire en sort qu'Ajax attende la réponse "OK" de la mise à jour de la base de données avant de pouvoir faire toute action sur le panier pour éviter tout problème (j'ai en particulier des boutons -/+, si un internaute "s'excite" sur le bouton +, ça permettra de le calmer).
Pour ce site : il s'agit d'une solution "home made"

 

[zeb]

j'ai en particulier des boutons -/+, si un internaute "s'excite" sur le bouton +, ça permettra de le calmer.

Pas con j'y avais pas pensé !

Remarque bien que si tu attend le retour de l'ajax pour lui modifier l'affichage, qui sera donc forcement en corrélation avec la base (du moins je pense) alors il peut cliquer autant qu'il veux l'affichage sera le reflet de la réalité.

Une solution facile serait en tous cas de désactiver le "onclick" en entrant dans le script javascript qui appel via ajax le serveur (en remplaçant la fonction "ajouter" par un "alert('calme ta joie')") et de rétablir après la réponse.

il s'agit d'une solution "home made"

ça me rassure je pensait être le seul tordu (désolé pour toi) a dev ce genre de truc ...
De mon côté j'ai intégré la base de données Prestachop sur mon CMS et je dev les fonctions qui vont bien dans ma structure (put1 que c'est lourd ).

 

[hp_angel]

Pas con j'y avais pas pensé !

Bah wé, y'en a dans la caboche

ça me rassure je pensait être le seul tordu (désolé pour toi) a dev ce genre de truc ...

Pas de mal, disons que ce site commence à avoir quelques années et qu'à l'époque Prestashop and co n'existaient pas... il y a les avantages et les inconvénients à avoir des trucs faits maison
Là en plus avec les passerelles développées spécialement pour l'ERP, je me demande comment j'aurais fait avec un CMS tout prêt, surtout quand une nouvelle version apparaît (et que parfois le schéma de la BDD change, comme c'est le cas avec la prochaine version de Prestashop... mais c'est un autre sujet ^^).
Par contre t'as fait fort en partant de la BDD de Prestashop... après une fois que t'as fait tes développements, tu sais où tu vas
Tu ne gagnes pas du temps sur la création, mais sur la maintenance et tu peux vraiment tout gérer... tout dépend de l'investissement que l'on est prêt à mettre pour un site (e-commerce ou autre) !

 

[zeb]

Tu ne gagnes pas du temps sur la création, mais sur la maintenance et tu peux vraiment tout gérer... tout dépend de l'investissement que l'on est prêt à mettre pour un site (e-commerce ou autre) !

Bah depuis le temps que je fais de la programmation (ça doit faire 27 ans maintenant), je me suis vite rendu compte de la vitesse d'évolution des softs et que le côté maj, maintenance était un facteur a prendre en compte. Bref quand je suis arrivé sur le dev web j'ai pas tergiversé 107 ans pour prendre le parti du fait maison. Comme tu le souligne maintenance et maj sont deux chose relativement light à gérer.

Dans le même esprit je suis en premier parti sur mes besoins donc gestion de contenu classique / forum / annuaire, par la suite j'ai ajouté le côté blog et glossaire, la vente en ligne est le dernier volet (c'est pas fini).

Il est certains que j'aurais un mal de chien a rentabiliser les heures de dev que j'ai mis sur ce projet mais bon je le regagne en tranquillité à côté.

Mon volet ultime concerne la virtualisation du système pour que le gestionnaire de contenu global deviennent un gestionnaire de domaine web afin de vraiment vivre pleinement le bonheur de ne plus rien installer ou presque. C'est encore en bêta mais c'est prometteur.

L'idée de la base prestachop est de pouvoir récupérer facilement des site existants en les changeant de système en un clin d’œil, j'ai pas encore eu l’occasion de tester mais on verra bien. ça m'a évité une grosse dose de conception sur le modèle que je paye cher en implémentation car c'est sacrement tordu ... Mais on a rien sans rien

 

[hp_angel]

ça doit faire 27 ans maintenant

Ah oui, quand même... Ca en fait du recul

j'aurais un mal de chien a rentabiliser les heures de dev

De toutes façons maintenant c'est fait, et puis la rentabilité c'est sûr que c'est un élément, mais il y a des fois où ça ne fait pas tout... Perso je suis en train de réfléchir à partir aussi sur une base de CMS existante que je vais personnaliser pour lui donner une indépendance (tout en surveillant les mises à jour de sécurité). A suivre !

Mon volet ultime concerne la virtualisation du système pour que le gestionnaire de contenu global deviennent un gestionnaire de domaine web

--> là j'ai eu l'impression de lire du chinois

Sinon pour en revenir au cookie, je vais voir pour coder ça ce soir ou demain, et je réfléchissais à la sécurisation du cookie (même si il n'y a pas de grand intérêt à éditer mon cookie pour mettre l'id d'un panier potentiellement existant, ça reste quand même un "trou" dans la sécurité). Je vais donc utiliser une fonction de hachage avec du sel pour parfaire tout ça.

Maintenant que le problème a été réfléchi, il n'y a plus qu'à coder !

 

[zeb]

là j'ai eu l'impression de lire du chinois

Je souhaite passer d'un soft qui gère un site (et que j’installe pour chaque site) a un soft qui gère tous les sites et qui est installé sur un serveur accueillant N sites.

Sinon pour en revenir au cookie, je vais voir pour coder ça ce soir ou demain, et je réfléchissais à la sécurisation du cookie (même si il n'y a pas de grand intérêt à éditer mon cookie pour mettre l'id d'un panier potentiellement existant, ça reste quand même un "trou" dans la sécurité). Je vais donc utiliser une fonction de hachage avec du sel pour parfaire tout ça.

Peut être associer ID_User a ID_Cookies (côté serveur) pour qu'un changement de cookies soit détectable côté serveur (l'ID_User n'a pas a être diffusé normalement).

Le souci est le cas du user pas connecté donc qui n'a pas d'identité établie. Mais a ce niveau il faut connaitre ta politique de paiement pour savoir si a l'ultime moment de payer tu dois être identifié sur le site ou pas ... auquel cas tu peut informer que quitter le site ou composer un panier sans être identifié est au risque et péril de l'utilisateur et qu'il ne pourra être récupéré / sauvegardé.

Le problème de la cryptographie dans les cookies c'est que tu confie la clé a l'utilisateur ce qui est a mon avis la pire solution comparé au fait de garder les clés pour soi.