Bonjour à tous,
 
Je vais construire un site genre commerce électronique et je me demande si je DOIS faire une session PHP ou s'il y a un autre moyen plus sûr ou plus simple ou s'il y a des restrictions à l'utilisation de la session.
 
Une fois que l'utilisateur s'est connecté (ou non), je voudrais "suivre" un peu tout ce qu'il fait sur mon site. Un peu comme les caddies sur les sites de E-Commerce : enregister ses recherches, ses "commandes en attentes", ...
 
- Est-ce que je dois faire passer des variables de session de pages en pages ?
 
- Est-ce que je dos utiliser des cookies ?
 
- Est-ce que je dois créer une table MySQL temporaire avec les données ?
Si oui, quand est-ce que je la détruit (pour ne pas encombrer le serveur), si par exemple l'utilisateur s'en va de mon site et n'y revient pas ET que c'est un utilisateur inconnu (= ne s'est pas inscrit) ?
 
Voili, voili...
 
Merci d'avance !

Par un moyen ou un autre, il faudra bien oui!

Pas nécessairement. Tu peux aussi passer un ID de session par les URL. Plus sûr puisqu'évite les refut de cookie par le client. Par forcément plus partique pour le développement.

Si tu code ton propre gestionnaire de session, ça me parait préférable.
Après, si tu utilise le gestionnaire de session de PHP, c'est pas indispenable.
Edit : La table n'est pas temporaire, les données qui s'y trouvent le sont.

Merci dwogsi !
 
Pourrais-tu me dire quels sont les avantages de créer mon propre gestionnaire de session ?
(si je comprends, c'est faire passer des variables que j'identifie dans mon code comme étant une session...)
 
Et pourquoi ce n'est pas indispensable de passer par une DB quand on utilise la session PHP ?
 
Merci d'avance

Je déconseillerais fortement le passage d'id par l'url. Sur ce genre de site, c'est cookies sinon rien...

Quel est le problème avec le passage de l'ID dans l'URL ?
 
Ne peut-on pas passer par une variable POST ?

une variable post à chaque changement de page? C'est méga lourd pour pas grand chose, quant à concaténer l'id de session dans l'URL, ça facilite la tache pour les emmerdeurs qui veulent faire du vol de session...

Tu ne peux pas mettre tous les liens du site en post, tu aura donc nécessairement du get.
 
Avec l'id dans l'url, y'a trop de risque que l'utilisateur copie un lien quelque part avec l'id dedans, donnant la possibilité à d'autres personnes d'utiliser sa session. Beaucoup de problèmes de sécurité peuvent être réglés avec les cookies (mais pas tous)

Sorry... ma question sur le POST n'était pas très maline !!
 
Donc en gros, comme le disais FlorentG, si on veut la plus grande sécurité c'est cookies sinon rien !!!
 
Il n'y a aucun moyen de sécuriser une session PHP !?

bien sur que si, heureusement d'ailleurs! Pour ma part, j'utilise le user agent du navigateur, combiné à un grain de sel aléatoire généré à chaque connexion d'un utilisateur, le tout haché et stocké dans une variable de session. le grain de sel est quant à lui stocké dans la table des utilisateurs et mis à jour à chaque génération.

ouais, m'enfin c'est pas compliqué d'éditer le fichier de cookie avec un éditeur de texte

Bien-sûr, mais le cookie, tu le transmets pas quand tu postes un lien quelques part, et c'est pas loggé par la planète entière.

J'ai crus voir deux trois trucs distincts dans tes questions :
- le panier : là, c'est soit stocké en cookie (risque de refus du cookie) soit dans la session (risque de péremption de la session) : attention, on ne stocke que l'identifiant des produits et la quantité, pas le prix.
- les commandes en attente : là c'est session obligatoire vu qu'il faut être identifié pour les consulter (il faut bien être sur que c'est la bonne personne qui va les voir).
- les derniers articles consultés : là c'est dans les cookies ou si la personne est connecté dans la base de donnée (histoire de lui indiquer plus tard quand elle revient)
- les articles consultés le plus souvent : là c'est dans la base de donnée uniquement. La session périme trop vite et les cookies ne peuvent pas tout contenir. Ca veut donc dire que c'est une option qui n'est disponible que pour les clients identifié.
 
Tu peux aussi rajouter des éléments du genre les recherche préféré (façon ebay) les alertes sur certains produits (pour indiquer quand ça sera à nouveau en stock ou s'il la rupture est définitive suite à un arrêt de la production) et quelques options sympathiques du genre qui seront toutes stocker dans la base de donnée.
 
Pour les sessions php, on peut stocker les valeurs dans des fichiers (comportement par défaut) ou les stocker dans la base de donnée (meilleure sécurité sur les serveurs mutualisés) je te laisse lire la doc et chercher éventuellement des tutoriels sur le sujet.
 
Pour les sessions de manière plus générique, certains utilisent le système fournis dans php alors que d'autres préfairent créer leur propre système en général pour appliquer des règles de validations différents.

hmpf
 
ben là ça dépend énormément de ta modélisation.
 
pour moi :
- panier : bdd
- commandes : bdd (même table, un simple statut permet de différencier les deux)
- articles consultés : bdd
- top articles : bdd
 
perso, je préfère tout stocker en bdd.
 
en cookie/session, uniquement les informations d'identification de l'utilisateur et autres éléments sans importance et aisément déductibles via le login, telle que la langue de consultation, monnaie, etc.
 
si le site plante ou que l'utilisateur ferme par inadvertance sa page, proutch, session ou cookie, t'as tout perdu (à la limite, avec le cookie, tu peux avoir du pot)
 
stocker dans la base, ça permet de commencer à constituer un panier, puis le récupérer le lendemain quand on a retrouvé sa carte bleue qu'on avait oublié dans la boite à gants de la voiture.
 
c'est d'autant plus important que cela limite énormément les injections liées au paiement en ligne.
un bon service de paiement en ligne, il charge une page pour l'utilisateur, et exécute une page dans ton site, qui ne contient ni session ni cookie. ainsi, t'es de toute façon obligé de passer par la base de données pour retrouver toutes les infos nécessaires à la validation ou invalidation de la transaction.

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)

Merci à tous !!
 
Je vais un peu potasser tout ça et voir ce qui me conviendra le mieux !

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)

S'ils ont pu acheter avec un prix 100 fois plus petit, c'est que t'as du stocker le prix hors de la base à moins que tu ne l'ai mis dans des input (caché?) des formulaires de choix des produits. (à noter que j'ai déjà vu les deux cas )
Ca n'est pas avec l'id d'un produit ou la quantité d'un produit qu'ils peuvent toucher au prix à part si tu ne vérifies rien auquel cas des quantités négatives baissent évidement le prix mais là le problème est le même avec un panier stocké dans la base de donnée.
Côté vérification, tu n'as pas plus de vérification à faire en stockant ces deux données dans un cookie ou dans la base vu que de toute manière elles arrivent tôt ou tard de l'extérieur. Le test est juste à refaire à la validation finale quand c'est stocké en cookie.
 
Enfin bon, t'as fait une gaffe un jour et t'es devenu parano ensuite. Moi j'ai vu des gas faire ces gaffes là et je me contente juste d'envoyer hors de la base les données temporaires peu dangereuse (qui n'ont donc pas vraiment de raison d'être dans la base). Pour les données critiques, c'est sur, ça ne quitte jamais la base sauf en lecture seule (affichage, calcul) et là on est tous d'accord sur ce point. C'est vrai qu'au final c'est deux façons d'organiser les données mais tant qu'on fait les vérifications qu'il faut avant d'utiliser ou de stocker des données venus de l'extérieur, aucune des deux solutions n'est plus dangereuse que l'autre.

Test qui n'en fini jamais lorsque tu as un site trop complexe avec des règles évoluées.
 
Si mon utilisateur, parcequ'il est français, n'a pas le droit d'acheter des objets nazis... Que se passe-t-il s'il modifie son cookie pour mettre le code d'un tel objet, qu'il aura récupéré d'une façon x ou y ?
Ca veut dire que lors de la validation, tu dois refaire une chiée de tests que t'as déjà fait de toute façon au moment de l'affichage, et certainement lors de l'ajout dans le panier.
 
Idem, pour les prix au volume. Je mets 1000 unités de mon produit dans le panier, et au moment de payer, je modifie le cookie pour passer la quantité à 1. Si tu ne te fais pas chier à chaque chargement de chaque page à refaire un appel prix complet, c'est la fin, le gars achète une unité pour le prix d'un lot par 1000.
 
Souvent, les appels prix ne sont pas bien compliqués à faire, mais quand ça repose sur 7 tables qu'on attaque successivement de 3 façons différentes chacune afin de retrouver le prix applicable pour un tuple client/produit, ça devient très gênant de devoir refaire le test à chaque fois.
 
C'est pour cette raison que je me refuse à stocker la moindre information succeptible d'ouvrir une faille, afin de contrôler à quel moment je dois faire mes tests, et les limiter le plus possible : dans mes deux exemples, ces tests n'ont à être exécutés qu'une fois, lors de l'ajout d'un produit et/ou changement de quantité.

Pour le site d'appel prix, je suis d'accord avec toi, c'est un cas très spécifique où il faut stocker en base pour des raisons de performances.
 
Pour l'autre cas, c'est quand même un cas assez rare. D'ailleurs, c'est un cas foireux même avec un stockage en base : s'il change l'adresse de destinataire, t'es quand même obligé de tout revérifier sinon il lui suffit d'indiquer par exemple "Afrique du sud" comme pays de résidence et le faire envoyer ensuite à son adresse réelle en allemagne par exemple (PS : En passant, en france il n'est pas interdit de posséder des objets nazi, du moins pas par ce que ça sont des objets nazi, mais il est interdit de les montrer en public sauf cas d'exceptions comme les reconstitutions historiques). En pratique, c'est un cas (objet disponibles que pour certains pays et non pas objets nazi) que je n'ai vu que pour une seule boutique en ligne : une boutique française de jeux de société qui dispose d'une succursale aux USA et dont le catalogue de la succursale ne comprend pas les versions françaises de tous les jeux vendus.
 
De mon côté, c'est vrai que je n'ai pas encore eu de cas spécifique qui nécessite de nombreuses tables de calculs de cas et 10 secondes de temps CPU par produits mais pour le moment, j'ai toujours fait une fonction de vérification du panier qui regroupe tous les tests nécessaire. Je l'appelle quand j'ai besoin et le tour est joué. Le jour où j'ai besoin de rajouter ou modifier une règle je n'ai qu'un seul endroit à modifier. Je ne risque pas d'oublier une vérification déjà faite à un endroit vu que tout est centralisé. En fait, en faisant comme ça, je n'ai pas eu de problème à gérer les cas complexes mais c'est vrai que je suis obligé de refaire une vérification de plus que toi.