8792 sujets

Développement web côté serveur, CMS

Panier

bonjour,

je voudrais réaliser un panier virtuel.
j'avais pensé le faire en php en utilisant les sessions, mais apparemment ce n'est pas possible car les sessions utilisent les cookies (où alors, si elles ne les utilisent pas, l'envoi de l'ID se fait par l'url, et ce n'est pas conseillé...)

je voudrais donc savoir comment contourner cette difficulté.
si quelqu'un peut me conseiller...

merci d'avance... Smiley cligne
Modifié par jerome1 (30 May 2005 - 13:50)
Modérateur
Utilise les sessions PHP, c'est tout. C'est le plus logique à utiliser si tu as accès à cette technologie.

Même si l'utilisateur n'a pas ses cookies, il y a moyen de faire passer son id de session dans l'url, comme tu l'as mentionné. Comme c'est simplement pour mettre des articles dans un panier, sans identification, juste pour acheter à la fin, même si un pirate viendrait qu'à voler le id de session d'un acheteur sur le site (en regardant dans l'historique ou par n'importe quel autre moyen), tout ce qu'il pourrait obtenir, c'est la liste des articles dans son panier. Il ne peut rien faire d'autres. C'est quand même juste un panier.
Administrateur
Salut,

Puisque c'est une question de PHP, le bon salon est celui des langages serveur.

Je rappelle néanmoins la règle de ce salon :
a écrit :
Ce nouveau salon est prévu pour prendre compte le rôle des scripts serveurs dans un site standard (X)HTML CSS (la gestion des divers informations spécifiées via HTTP sur le type de contenu, la langue, etc.).

Il est strictement réservé aux questions ayant un rapport avec les standards web et leur application via des langages serveur comme PHP, ASP, Coldfusion ou .NET.
Merkel a écrit :

tout ce qu'il pourrait obtenir, c'est la liste des articles dans son panier.
Il ne peut rien faire d'autres.

c'est bien sûr, je peut utiliser les sessions avec use_trans_id()...?
il n'y aura pas de trou de sécurité...?
en fait je peux m'en servir pour la création du panier et ensuite, si l'on passe au paiement par exemple, c'est là qu'il faudra changer de méthode...?

CCC a écrit :

Salut,

Puisque c'est une question de PHP, le bon salon est celui des langages serveur.

pardon, c'est parce que j'ai vu "salon général et débutants"
Modérateur
En fait, je crois qu'il y a moyen de dire à PHP que si les cookies sont inactifs chez le client, automatiquement passer le ID de session dans l'url. Pour le reste, j'en sais rien, je ne code pas en PHP.

Pourquoi changer de méthode pour le paiement ? Il s'agirait tout simplement d'un formulaire sécurisé SSL (https) où le client entrerait son numéro de carte de crédit et ses informations. Cette même page aurait récupérée le contenu du panier dans la session.

Le seul risque selon moi de passer les ID de session dans l'url c'est lorsque tu as une section protégée par mot de passe. Où la personne doit s'identifier pour accéder à son compte personnel. Dans un tel cas, je force les visiteurs à activer les cookies. C'est plus sûr.

C'est beau vouloir donner de la liberté aux visiteurs (pas de cookie activé), mais pas au prix d'une application moins sécuritaire.
Merkel a écrit :
Le seul risque selon moi de passer les ID de session dans l'url c'est lorsque tu as une section protégée par mot de passe. Où la personne doit s'identifier pour accéder à son compte personnel. Dans un tel cas, je force les visiteurs à activer les cookies. C'est plus sûr.


Argle... tu veux ma mort ou quoi ! Ça avait bien commencé, mais ça finit en eau de boudin ça ! Du point de vu de la sécurité, il n'y strictement aucune différence entre l'utilisation des cookies et le passage de parmètres dans l'URL !

C'est d'ailleur cette idée qui à l'origine de la mauvaise réputation des cookies en therme de sécurité ! Par définition, un identifiant passé de page en page peut être capturé par une personne indélicate. Le seul moyen a peut près efficasse de limiter (et pas de resoudre) le problème et de faire une double autentification à la fois par le passage d'un numero identifiant unique couplé à une vérification systématique de l'IP du client !

Bon, ce n'était pas spécialement le sujet du post, donc je ne vais pas m'ettendre sur la question, mais une stratégie de sécurité doit se penser bien au delà du simple transfert d'informations entre le client et le serveur car toutes les informations transmises par le client sont de toute façon douteuses !
Smiley smile
Modérateur
Jep a écrit :

Argle... tu veux ma mort ou quoi ! Ça avait bien commencé, mais ça finit en eau de boudin ça ! Du point de vu de la sécurité, il n'y strictement aucune différence entre l'utilisation des cookies et le passage de parmètres dans l'URL !


Tu m'as mal compris. Je ne parlais pas du transfert via Internet de l'information sensible, mais bien du côté sécurité avec le navigateur. Lorsqu'on passe le ID de session dans l'url, c'est facilement visible par la personne qui est juste à côté du client ou qui va consulter l'historique par la suite. On peut bien effacer l'historique, mais c'est pas tous les clients qui vont y penser. De plus, avec IE par exemple, j'avais beau effacer mon historique, il restait toujours des traces. Je tappais par exemple les premières lettres du forum alsa, et je voyais le chemin vers un message précis que j'avais visité. Pourtant, mon historique était effacé. Je trouve plus sûr les cookies juste pour ca. Je ne parlais pas au niveau de la transmission vers le serveur.

Au sujet de la technique du couple ID et IP, c'est plutôt difficile. C'est pas tout le monde qui a une IP fixe et d'ailleurs, certains visiteurs passent par des proxys dynamiques (si je me trompe pas) et leur ip peut changer en court de session.

Donc ne te trompe pas, je parlais bien de la sécurité côté client et non de la sécurité au niveau de la transmission des données.
Modifié par Merkel (30 May 2005 - 15:42)
Modérateur
Autre chose qui me turlupine à propos du passage du ID de session dans l'url. Je vois parfois dans mes statistiques de visite de l'un de mes sites des REFERERS. Des pages de provenance. Certaines comportent des paramètres dans l'url. Donc je me dis que si ces paramètres sont envoyées par le navigateur comme REFERER, alors je pourrais très bien me retrouver avec des REFERERS comportant des ID de session dans l'url. Très risqué. D'ailleurs, les gens qui achètent sur le web ne savent pas trop non plus à quoi correspond ce long url, et peuvent par erreur faire un copier-coller de leur adresse pour montrer un produit à quelqu'un. Ce que le client ne sait pas c'est qu'il vient d'envoyer son ID de session avec l'adresse de la page du produit.

C'est ce que je voulais dire en parlant que les cookies étaient plus sécuritaire.
Modérateur
Jep a écrit :

Du point de vu de la sécurité, il n'y strictement aucune différence entre l'utilisation des cookies et le passage de parmètres dans l'URL !


Donc voilà Jep, je pense avoir déjà résumé plusieurs points qui font en sorte que oui, les cookies sont plus sécuritaires que le passage des paramètres dans l'URL. Quand je parle de plus sécuritaire, je ne veux pas dire infaillible. Mais toujours plus sûr que par l'URL.

Avantages du cookie, qui sont inversement les failles du passage par l'url :

1. La personne située tout près du client ne peut pas voir son id de session dans la bar d'adresse.

2. Même si l'adresse de la page est stockée dans l'historique ou les favoris, le ID de session ne sera pas visible facilement.

3. Aucun danger qu'un client montre son id de session à un autre individu simplement en voulant lui refiler l'adresse d'un produit.

4. Lors de l'impression, si l'url est ajoutée à l'entête, on ne voit pas non plus le ID de session.

5. À partir du site marchand, si le client clique sur un lien vers un site externe qui log les REFERERS envoyés par le navigateur, l'administrateur des statistiques ne pourra pas voir des ID de session.

Ceci n'est que 5 points. J'en ait probablement échappé d'autres. J'en conclu donc que oui, les cookies sont plus sécuritaire que l'url et qu'il y a une différence majeure au point de vue de la sécurité.

Pour ce qui est de la transmission des données client-serveur, c'est une autre histoire. Smiley cligne
Modifié par Merkel (30 May 2005 - 18:09)
Merkel a écrit :
les cookies sont plus sécuritaires que le passage des paramètres dans l'URL. Quand je parle de plus sécuritaire, je ne veux pas dire infaillible. Mais toujours plus sûr que par l'URL.

Oui et non... en fait, c'est une vision un peut schématique que tu donnes, mais bon, c'est vrai que le simple fait que l'identifiant de session soit invisible est une forme de protection supplémentaire, mais qui ne resistera pas une seul seconde à quelqu'un de déterminer à capturer un identifiant de session.

Merkel a écrit :
2. Même si l'adresse de la page est stockée dans l'historique ou les favoris, le ID de session ne sera pas visible facilement.

3. Aucun danger qu'un client montre son id de session à un autre individu simplement en voulant lui refiler l'adresse d'un produit.

5. À partir du site marchand, si le client clique sur un lien vers un site externe qui log les REFERERS envoyés par le navigateur, l'administrateur des statistiques ne pourra pas voir des ID de session.

Le fait d'accèder a un ID de session via l'historique n'a normalement, dans un système correctement sécurisé, aucune incidence. En effet, une session ne doit normalement pas perdurer avec le fermeture d'un navigateur et doit être détruite automatiquement au bout d'un certain temps (en général, 2h) si on ne ferme pas son navigateur. Or, une fois un ID de session expiré, sa connaissance n'a aucun interret !

Dans tous les cas, ce qu'il faut retenir, c'est que toutes informations transmise par le client n'est pas fiable et peut être détournée (même une adresse IP !)

Il faut donc prendre toutes les mesures necessaire pour s'assurer de la qualité des informations du client, mais il est totalement impossible de garantir une inviolabilité à 100%

Et donc, oui Merkel, tu as raison, les cookie sont "plus sur" dans la mesure ou les informations qu'ils fournissent ne sont pas directement visible et exploitable par un tiers.
Smiley smile
Modérateur
Jep a écrit :

Le fait d'accèder a un ID de session via l'historique n'a normalement, dans un système correctement sécurisé, aucune incidence. En effet, une session ne doit normalement pas perdurer avec le fermeture d'un navigateur et doit être détruite automatiquement au bout d'un certain temps (en général, 2h) si on ne ferme pas son navigateur. Or, une fois un ID de session expiré, sa connaissance n'a aucun interret !


Je suis d'accord sur ce point mais dans le cas des REFERERS stockés dans les statistiques, un administrateur éveillé pourrait très bien avoir le temps de voler la session du client, puisque ce client est encore en ligne avec la même session. Même chose si le client envoi l'url en cours à une personne pour qu'elle consulte le même produit. Sa session est toujours ouverte, puisque le client est encore en ligne.
Sujet clos
Aller à