Ecommerce, comprendre le panier lié à l'identifiant

Bonjour à toutes et à tous

Je me pose une question technique au niveau de la programmation d'un site de ecommerce.

J'ai créé mon site de ecommerce. Seulement, il faut d’abord s'inscrire avant de pouvoir commander et remplir son panier.

Comment fonctionnement les paniers qui permettent de remplir son panier sans s'identifier, puis l'identification se fait qu'au moment de payer son panier ?

Dois je récupérer l'IP du client comme identifiant temporaire et unique ? Puis enregistrer les achats dans une table temporaire?

ou Dois je utiliser la passation de champs masqués jusqu'au règlement de la commande ?

J'ai beau me creuser les méninges je ne vois pas comment faire. Avez vous une petite idée ?

Cool merci
En fait il faut utiliser des cookies tout simplement ?

Les Cookies peuvent être utilisés, mais ne sont pas obligatoire. C'est la session qui est importante.

Salut,

Laurie-Anne a écrit :
Les Cookies peuvent être utilisés, mais ne sont pas obligatoire. C'est la session qui est importante.

Cela dit, lorsqu'une session est ouverte, un cookie est utilisé, à moins de faire en sorte que les sessions soient gérés via le paramètre d'URL PHPSESSID (ce qui peut s'avérer casse-pied, notamment pour le référencement).

Hello, Bon Dimanche,

rakoons a écrit :
Cool merci
En fait il faut utiliser des cookies tout simplement ?

L’état d’une page peut également être embarqué dans la page elle-même : par des attributs d’éléments (ne te soucie pas trop des erreurs de validation dans ce cas, et utilise un nom de la forme data-xxxx), dans un éléments, dans champs de formulaire pré-initialiser.

Selon que tu n’utilise que PHP ou que tu utilise XmlHttpRequest, les solutions sont également différentes, puisqu’il n’y a pas de rechargement de la page.

Il faut éviter les cookies, parce qu’il n’associe pas une page à son propre état. Ils ont cependant l’avantage de partager l’état entre plusieurs page.

Ou sinon, comme l’a fait remarquer Victor Brito, tu peux utiliser un identifiant de cession dans l’URL, et conserver l’état de la page sur le serveur.

L’avantage est de pouvoir partager l’état entre plusieurs page, mais avec un risque de perte de l’état si l’utilisateur prend une pause trop longue.

Depuis quelque temps, s’ajoute même le stockage de données associées aux pages (avec les fonctionnalité de HTML5).

Bref, comme tu le comprendra je pense, cette question n’est pas spécifique à la gestion d’un panier dans une boutique en ligne, mais est une question générique de la conception des applications web : la conservation d’un état… et les solutions sont multiples.

Pour décider de la solution à choisir, tu dois prendre dans ce que tu maitrise déjà, dans ce qui se marie le mieux à ton design, ou tenir compte de toutes autres contraintes techniques que tu a éventuellement.
Modifié par hibou57 (17 Jul 2011 - 10:20)

Oui, le scénario du risque que tu présente est fondé, mais il est peut être évité. La méthode peut être d’associer une IP éventuellement passée à travers un masque (j’explique après), et de valider le couple identifiant de cession + IP ou lieu de seulement l’identifiant de cession.

On peut vouloir appliquer un masque, parce que les gens n’ont pas une IP fixe, c’est connu. Une coupure de la connexion à internet suivie d’une reconnexion automatique, peut changer l’IP.

Mais le changement d’IP ne se fait pas n’importe comment. À cause du fonctionnement du réseau et de la manière dont les FAI organisent leur distribution et gèrent leurs IP, seul une partie de l’IP change. Souvent, seul l’octet le plus bas change. Donc on peut retenir par exemple 123.456.789.xxx (c’est le masque dont je parlais).

Pour démontrer qu’elle tient la route, cette technique est utilisée avec les forums PHPBB (on peut configurer le masque dans l’administration [*]).

Formellement, le risque n’est pas totalement éliminé (aucun ne l’est jamais de toutes façons), et l’internaute pourrait théoriquement toujours se faire voler son identifiant de cession par son voisin ou un autre habitant de son quartier (ça peut aller jusqu’à un rayon de 4 ou 5 km, à la louche dans le pire des cas), mais le risque est bien réduit.



[*] Aller dans l’administration, puis Général, puis Paramètre de Sécurité (dans la liste à gauche), puis dans le corps de la page, chercher « Validation de session IP ». Cette option a un commentaire qui l’explique bien :

PHPBB a écrit :
Détermine quelle partie de l’adresse IP des utilisateurs sera utilisée pour valider une session : Tous compare l’adresse complète, A.B.C les premiers x.x.x, A.B les premiers x.x, Aucune désactive la vérification. Pour les adresses IPv6, A.B.C compare les 4 premiers blocs et A.B les 3 premiers blocs.

Et les choix sont : Tous, A.B.C, A.B, Aucune.

J’ai choisi personnellement A.B.C, pour les raisons données plus haut.
Modifié par hibou57 (17 Jul 2011 - 22:24)

On revient de ce fait à ma question initiale : si je peux pas utiliser un identifiant de session temporaire de type ip (alors que pour moi l'ip est unique (et pourquoi hacker une ip temporaire d'ailleurs)

Comment dois je procéder pour charger un panier avant une connexion du client ?

En tout cas merci pour vos réponses multiples

rakoons a écrit :
On revient de ce fait à ma question initiale : si je peux pas utiliser un identifiant de session temporaire de type ip (alors que pour moi l'ip est unique (et pourquoi hacker une ip temporaire d'ailleurs)

Comment dois je procéder pour charger un panier avant une connexion du client ?

En tout cas merci pour vos réponses multiples

Je résume :

1. Pour stocker les données avant connexion (et même après) tu utilises les sessions.
2. Tu prends bien garde de ne pas transmettre l'id de session par l'URL. Pour ça tu configure ton PHP soit directement dans ton php.ini soit en rajoutant ces lignes dans ton .htaccess :

php_flag session.use_cookies On
php_flag session.use_only_cookies On
php_flag session.use_trans_sid Off

Tu pourrais utiliser un cookie pour faire ça mais c'est moins adapté. Avec un cookie les données sont stockés sur l'ordinateur de l'utilisateur, avec les sessions elles sont stockées sur le serveur. Avec un cookie les données sont donc transmises à chaque ouverture de page depuis l'ordinateur de l'utilisateur jusqu'au serveur. Avec les sessions elles sont accessibles directement depuis le serveur.

De plus les cookies ont des limitations que les sessions n'ont pas : taille des données stockées limitée, on ne peut pas y stocker n'importe quels types de données.

L'avantage des cookies c'est que les données sont accessibles tant que le cookie n'a pas expiré, c'est à dire que l'internaute pourrait fermer son navigateur et revenir sur ton site un autre jour et les données seraient toujours accessibles : c'est pratique pour stocker les préférences du site comme la langue, les informations de connexion (pour une connexion automatique) et ce genre de choses.
Modifié par jb_gfx (18 Jul 2011 - 14:31)

jb_gfx a écrit :
L'avantage des cookies c'est que les données sont accessibles tant que le cookie n'a pas expiré, c'est à dire que l'internaute pourrait fermer son navigateur et revenir sur ton site un autre jour et les données seraient toujours accessibles

Vi, c'est comme ça que fonctionne Amazon par exemple.

Le « pauvre » Rakoons, il vient ici pour poser une question en espérant une réponse claire, et il reçoit des suggestions toutes contradictoire

@Rakoons : comme tu l’as bien compris, les solution sont multiples, et puisque l’on parle de panier ici, c’est maintenant à toi de faire ton marché, ton choix

Ce serait difficile d’aller plus loin, parce que là tout à été dit.

Concernant la sécurité, tu peux noter que à partir du moment où tu sais d’où peut venir la faille, tu peux la corriger. Aucune des méthodes ne peut être qualifiée de non-fiable par nature; toutes peuvent être appliquée de manière fiable (enfin, pour simplifier, parce que fiable à 100% n’existe jamais). Il faut que tu t’en remettre à tes propre critère pour faire un choix définitif (une chose que tu dois savoir faire, puis tu peux conserver ce fil comme un mini-aide mémoire maintenant).
Modifié par hibou57 (18 Jul 2011 - 21:02)

Oui, sauf qu'il y a des solutions peu recommandables qui comportent plus de risques au point de vue de la sécurité. Le ID de session est une donnée sensible qu'il faut protéger. La transmettre dans l'url est le pire moyen d'y parvenir. Serais-tu à l'aise d'aller dans un cybercafé et que ton mot de passe d'utilisateur apparaisse clairement en haut de l'écran? C'est exactement ce qui se passe avec le id de session dans l'url. La personne qui passe derrière toi peut prendre une simple photo par-dessus ton épaule et ensuite s'identifier avec ta session sur le poste d'à côté avec la même adresse IP.

La solution du cookie est beaucoup plus sécuritaire, même si elle ne protége pas contre tout.

À noter qu'associer l'adresse IP à la session peut s'avérer une protection supplémentaire efficace, même en ce qui concerne l'utilisation d'un cookie pour stocker l'id de la session.