Discussion :

[infocoldzero0]

Bonjour,

Mon site utilise du jQuery afin d'appeler des pages php qui agissent comme des fonctions qui retournent true ou false si le traitement s'est bien fait ou pas:

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$.ajax({
type: "POST", 
url: "/official/includes/validatePayment.php",
data: "PaymentPrice="+ "3.99", 
success: function(msg){
...

Mon problème est qu'il est possible, avec "Web Developer" sur firefox par exemple, de contrôler les valeurs envoyés en "post". Ma page validatePayment reçoit $_POST['PaymentPrice'] et fait le traitement en fonction de ce dernier. Comment "contrôler" la provenance des variables afin que les gens n'envoient pas des informations faussées ?

Merci énormément !

[Bovino]

Ben... pour la faire courte, envoyer un prix en AJAX ou via un formulaire est tout simplement suicidaire !

Il faut envoyer une référence par exemple qui te permettra côté serveur à récupérer le prix.
L'affichage côté client est une information pour l'utilisateur, rien de plus !

[shell13010]

Bonjour,

@Bovino Peux-tu détailler stp?

Car ma logique me donne:

-Si prix envoyer au server

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<-Server renvoie les données au site pour vérification

-Site:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

->on compare les champs par rapport a se reçu

-Si vérification= Bon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-> on envoie au server pour traiter le payement et envoie les données sur site

-Site récupere si Bon alors ok sinon invalide...

Je peux me tromper, mais envoyer des prix par formulaire ou ajax n'aurais aucune incidence si on vérifie ensuite non?

[sabotage]

Il n'y a pas de comparaison entre serveur et client.
Les informations sont detenues par le serveur ; le client ne fait que de l'affichage.

client -> serveur : je veux 1 article x
serveur -> client : ca coute €€
client -> serveur : je veux 2 articles x
serveur -> client : ça coute €€
client -> serveur : je paie
serveur -> client : ok, je facture les €€ que je t'ai annoncé.

[shell13010]

Effectivement, vue comme sa

en tout cas merci @Sabotage pour tes détails...

[RunCodePhp]

Effectivement, vue comme sa

Certes, mais pas tant que ça.

En général (je dis bien en général), un site e-commerce ne récupère pas les coordonnées des cartes bancaires ni même la transaction (le paiement).

Le site sous-traite cette action ou service via divers systèmes de paiement (banque, etc ...).
Ne serait-ce que pour une question de responsabilité.

Cela sous-entend que le site à un moment ou à un autre devra communiquer au minimum le montant total à payer au service en question.
Cela veut dire que l'information sera transmise via le réseau (Internet) du site vers l'autre site (le service en question : banque etc ...).
Donc via POST ou GET.

Ben... pour la faire courte, envoyer un prix en AJAX ou via un formulaire est tout simplement suicidaire !

Alors ça voudrait dire qu'il y aurait un sacré gros paquet de e-commerçants au bord du suicide.
J'aurais du faire Psi, un vrai métier d'avenir
(je déconne )

Ce qui veut dire qu'un plus malin que les autres aura la possibilité de modifier ces informations qui transiteront, entre autre le montant à payer.


Ceci dit, un site e-commerce ou une activité e-commerce devrait prévoir de recalculer le montant total à payer par rapport aux divers produits commandés pour le comparer à celui payé au service.
Le service bancaire fourni théoriquement un N° de transaction accompagné du montant payé par le client.
S'il y a un écart, c'est qu'il y a quelque chose de louche.


Quoi qu'il en soit, en général ce n'est pas le client qui fixe le prix à payer, mais le commerçant.
Au même titre que le supermarché du coin (les prix sont juste affichés à titre indicatifs).
A par quelques exceptions, comme les dons, enchères, etc ...