Bonjour

j'ai developpé une boutique en ligne, avec paiment sur la plateforme Cybermut (athos).
Pour envoyer les infos du panier à la banque, la doc du kit demande d'utiliser un GET, donc je cree une url qui balance non seulement l'identifiant du panier, mais aussi le prix !

N'importe qui peut pourrait modifier la variable du prix dans le get et passer une commande !
un POST serait il suffisant pour sécuriser la transaction ?

Je suis sur qu'il y a une solution éprouvée a ce genre de problème, si vous avez des lumieres, merci

mika

je précise que je suis encore en environnement de test

regardes comment magento fait.. Et pour info, Cybermut, c'est crédit Mutuel, pas Atos. Atos, c'est SIPS

 
Ok c'est sympa pour l'info mais ca ne m'apprend pas grand chose http://enterprise-demo.magentocomm [...] t/onepage/
et je me vois mal eplucher les classes de magento pour le reverse-engineriner, tu pourrais pas etre un poil plus explicite ?
 
+1 pour athos, ca m'évitera de dire des conneries  

Salut,
 
En général ce que tu fais c'est que le bouton "Acheter" sur ta boutique appelle un script PHP, toujours chez toi, qui lui, effectue l'appel vers le serveur de la banque avec les variables qui vont bien en GET.
Tu peux utiliser CURL pour ça, sinon il y aussi d'autres solutions mais je ne me rappelle plus le nom.
 
A+

Yes en effet, depuis le formulaire de validation d'achat, j'appele la page 'call_request.php' fournie en exemple par cybermut, qui est dans le dossier cgi-bin. C'est elle qui recoit les infos en GET. Il s'y affiche le choix du type de CB (VISA, MASTERCARD, ...)
le script appelle ensuite les executables qui redirige vers le server de paiement.
 
Et du coup je pense comprendre mon erreur : le pb n'est pas entre l'appel de mon site vers le server, mais dans l'appel de call_request.
il faut que je securise le transfert des variables entre le panier et call_request ... tu préconises cURL pour ca ?
 
Merci

Salut,
 
À vrai dire FOpen suffirait probablement. Après faut que tu voies ce que tu as besoin de récupérer comme info & co.  
Essaie déjà avec FOpen qui est plus simple.

ok cool je vais plancher la dessus.
pour les infos c tres simple, la reference de la commande et le montant ...
 
merci a toi

Tiens par contre cybermut c'est bien credit mutuel (ou cic) mais cela appelle bien SIPS , donc athos !

atos, pas athos
Y'a des chances car dans SIPS, y'a aussi un script call_request.php
 
Question : tu développes ta propres boutique en ligne pour de la prod ou c'est juste par curiosité intellectuelle? Parce que côté sécurité, ça me rassure plus d'acheter sur une boutique reposant sur magneto ou tout autre produit connu que sur une boutique développée par un seul gars (même si on ne le sait pas forcément)...
 
Edit : pour passer les variables, pourquoi pas via la session sinon, regarde cette extension pour magento : http://www.magentocommerce.com/mod [...] -extension

Je suis developpeur, mais principalement flash. C'est une boutique en prod, initialement prévue sous prestashop mais finalement on a opté pour un dev perso. le gros du dev etait plus sur le flash que sur le backoffice, donc ca n'a pas été trop pénalisant.
Après, vu la question que je pose, je comprends qu'on puisse se poser des questions sur la securité du systeme... mais dans tous les cas, le risque est pour mon client et pas l'utilisateur, puisque la transaction se déroule sur cybermut. right ?
 
Concernant les cms, ils ne sont pas tous si sécurisés que cela à mon sens, et surtout il y pas plus de monde qui pistent les failles (l'inverse est vrai aussi   ). Je suis pas sur que ce soit une garantie absolue. Et pour une fois que j'ai l'occasion de tout faire 'from scratch', ça a ajouté une dimension de curiosité intellectuelle
 
une session ca me parle dejà plus que fopen, d'autant que j'ai deja un systeme de cookies en place. Mais la je sens que j'ouvre la boite de pandore des failles de sécurité !

Je parlais de session côté serveur of course, pas côté client.
Développer from scratch une boutique en ligne, autant à l'époque d'Oscommerce, je comprends, autant avec un soft comme magento, là, je vois pas l'intérêt car il est super complet et y'a la boîte Varien qui gère le projet. Cela dit, Prestashop est très bien aussi. Donc pourquoi du dév sur mesure
 
Côté sécurité, comment vous stockez les transactions (N° de cartes bancaires par ex) en attente de validation ou celles passant en x fois? Y'a bien un risque pour l'utilisateur si un hacker arrive à vous piquer votre BD J'avais vu y'a qq mois un reportage sur des cybermarchands qui se faisaient hacker leur BD en la cryptant ou en la vidant et rendue contre rançon au proprio.... Je serais votre client, ça me ferait peur qu'on file une boutique développée from scratch. Avec magento ou prestashop (ou tout autre produit qui a une grosse communauté et du retour d'expérience), ça rassure plus...

la veritable raison etait assez lamentable : on s'etat mis d'accord pour prestashop, mais le serveur de mon client (qui heberge pas mal de sites) etait en php4; inconpatible avec presta. Ca a bcp pesé ds la decision d'autant que le client avait une mauvaise experience avec oscommerce et moi avec joomla
 
apres il faut aussi prendre en compte que le concept du site est unique (personnalisation avec rendu 3d) et qu'il n'exste aucun module sur aucun cms pourle gerer. Donc je n'avais pas specialement envie de me lancer dansun cms que je ne connais pas (magento) pour faire du dev de module pas foecement simple : autant tout gerer moi meme, ca limitait les variables inconnues
 
Par contre entre temps le client s'est decidé a passer a php5; j'etais    !!
 
pour les sessions oui, ca semble etre la bonne solution; eventuellement en rajoutant une petite encryption md5 pour etre sur
 
aucune données de paiement n'est stocké sur le server; on ne gere pas les credits. les fonctions de vente sont assez basique.... il n'ya donc aucun danger pour l'utilisateur.

Effectivement, la raison est complètement naze! Pourquoi ne pas avoir mis  une 2ième interface PHP sur le serveur Moi, j'ai un serveur de prod où j'ai 2 environnements PHP : un apache avec PHP4 et mysql 5 et un autre apache avec php5 et le même mysql (mais j'airais pu mettre un autre mysql).