MagicBuzz | omega2 a écrit :
Moi, je ne vois pas l'intérêt de pourrir la table des commandes avec des paniers qui ne seront jamais validés. Si tu savais le nombre de fois que j'ai remplis un panier sur un site juste pour voir si je pouvais me payer ce que je veux, tu serais étonné. En plus de ça, je déteste aller sur un site, y revenir un ou deux mois plus tard, choisir un ou plusieurs produits et devoir ensuite virer les articles qui m'attendent sagement dans le panier depuis longtemps et qui ne correspondent plus du tout à ce que je veux.
Si je veux vraiment garder en mémoire un ensemble d'article, je préfaire largement un bouton pour les mettre en favoris. D'ailleurs certains sites permettent de mettre en un clic tous les articles du panier dans les favoris et inversement et c'est un truc que je trouve très pratique.
Au fait, je ne vois vraiment pas le rapport entre avoir un panier dans le cookie et les injections du paiement en ligne. Que je sache, tu crés une commande à partir d'une liste d'article et de quantité. Quand aux prix, tu les récupères dans la base de donnée quelque soit l'endroit où est stocké le panier. Franchement c'est quoi le pire qui peut arriver avec un panier dans le cookie? Que le client mettes des quantités négatives? Si c'est le cas, on force à zéro et donc on vire le produit. Qu'il commande un produit inexistant? Idem viré. La faille serait de ne rien vérifier mais ça c'est valable aussi avec le panier dans la base de donnée quand le client modifie les quantités par l'administration. Par contre, là où je te rejoint, c'est si un développeur s'amuse à stocker le prix du produit dans le cookie et là ça serait du suicide commercial. Mais bon, il y a la même règle avec la base de donnée : ne jamais stocker un tarif dans le panier ne serais-ce que si le tarif change entre la sélection et la validation (qui peut survenir plusieurs heures plus tard)
|
Ben ça m'est arrivé plus d'une fois sur des sites, vai bidouilles extrêment simples, d'envoyer à l'admin du site une page de paiement par carte bleue prête à me valider une transaction où le montant avait été divisé par 100 par mes soins...
Si tu passes par la base, t'es sûr d'éviter ce genre de failles.
La règle, c'est de ne JAMAIS avoir côté client la moindre information autre que ses informations de connexion. Tu dois systématiquement tout re-déduire dans tes pages en ce qui concerne le panier, la tarification et autres éléments critiques, uniquement à partir du profile.
Sinon c'est vraiment trop "simple" de mettre en périle l'intégrité du site.
En tout cas, c'est un principe que je mets systématiquement en place, et je suis sévèrement hostile à toute autre méthode : autant c'est facile de mettre au point des procédures de nettoyage de la base par exemple, autant passer en revue toutes les exploits pour vérifier que la méthode peu sûre résiste à tout type d'attaque, je trouve ça trop risqué. Habituellement, je ne conserve en session/cookies que des informations très basiques telles que login/pass, langue, société -pour un site multisociété-).
Sinon, de manière classique, je ne permet jamais la constitution de panier sans être identifié. Mais bon, j'ai toujours travaillé sur des sites nécessitant obligatoirement un compte. Par exemple :
- General Electric : Chaque client bénéficie d'une tarification spéciale, selon une série de critères, tels que des appels d'offre, des réductions par zone géographique, secteur d'activité, etc.
- Groupe Seb International : Site réservé aux salariers et actionnaires afin de bénéficier des produits aux prix usine.
- Clust/Adiligo : Sites d'achats groupés, où on s'engage sur un prix pour une quantité donnée (plus un site de mini-appel d'offres en fait qu'un site de VPC) |