18041 sujets

Questions générales et questions de débutants

Additions et système anti-fraudes php

Bonsoir,

J'ai besoin de vos avis sur une certaine question, je suis en pleine réflexion.

Je voudrais mettre un programme de fidélité en place auprès d'utilisateurs de restaurant.

Pour prouver qu'une personne est bien aller manger auprès de nos partenaires, le plus simple que j'ai trouvé est que l'utilisateur envoi une photo de l'addition juste après son repas.

Malheureusement niveau sécurité j'ai comme l'impression que cela est impossible pour plusieurs raisons dont je réponds plus ou moins du mieux que je peux :

- Comment savoir si un utilisateur à déjà envoyé cette addition ?

--> début simple, on récupère un élément du ticket unique que l'on inscrit dans la base par traitement en amont et vérification

- Comment savoir si un utilisateur ne "photoshop" tout simplement pas ces additions pour changer cet id ?

On rentre dans le plus complexe...

--> Faire en sorte de devoir passer par notre application avec gestion de clé pour être sur que la personne ne passe pas par son ordinateur pour up la photo.

Oui, mais et si la personne photoshop l'image et le met directement sur son portable ?

--> Il faut donc faire en sorte que seul la caméra soit disponible, pour s'assurer qu'il s'agisse bien d'une photo prise dans l'instantané et par un appareil le permettant

Mon champs input devant ressembler à : <input type="file" accept="image/*" capture="camera">

On sait que tout ce qui est côté client est modifiable, rien n'empêche l'utilisateur de connecter son téléphone à son ordinateur pour pouvoir modifier le code source client de l'app en cours (possible ?) et enlever capture="camera", ou bien encore d'utiliser un navigateur qui ne supporte pas cette commande, pour pouvoir upload les photos modifiés.

--> Lire les meta de l'image en PHP pour bien voir que sa date de création est toute récente (de quoi pas laisser le temps à la modification)

Mais là encore les metas d'un JPEG peuvent être modifiés je me trompe ?

Alors voila, je me demandais si vous aviez des idées pour "renforcer" au maximum le système contre la fraude ou au contraire qu'il est plus judicieux de laisser tomber cette manière de faire en prenant en compte le "never trust user"

Merci pour vos retours, bonne soirée à tous !
Bonjour,

Perso je pencherais sur un ID unique à chaque ticket édité à cet effet. Au moment de l'édition de l'addition, un code apposé au ticket (avec éventuellement des instructions pour le client).
Côté Bdd, cet ID unique généré à la volée est enregistré en BDD avec une date d'expiration assez courte (quelques jours max) ; j'en profiterais même pour enregistrer le détail de la commande et le montant, ces données pourraient servir à des fins de statistique (par exemple).

Le client saisi cet ID sur le site internet. Bien sûr il a la faculté de saisir ce qu'il veut et peut tenter moulte combinaison mais... il est confronté toujours à la même réponse : votre code est en attente de validation, celle-ci sera effective sous x temps

Côté serveur, une vérification est effectuée pour vérifier si l'ID existe, s'il n'est pas périmé et s'il n'a pas déjà été saisi.

Ensuite le compte utilisateur est crédité du bonni afférent.

Dans le cas où le code est erroné, dans le compte du client (sur le site internet bien sûr) seraient enregistrés :
* l'id saisi
* la date de saisie (horodatage)
* le statut (en attente de validation, validé, rejeté)
* le bonni obtenu
Si vous constatez un nombre important de rejets vous pourrez prendre des dispositions (comme bannir ce compte utilisateur)

Dans les conditions générales d'utilisation j'ajouterais la possibilité de supprimer rétro-activement tout bonni constaté comme frauduleux.

J'ajouterai aussi des limites (genre 2 id max par jour à raison de une toutes les x heures et 6/semaine par exemple).

Et si vous en avez les moyens, vous pourriez coupler le site internet avec une application qui permettra de saisir facilement un ID et consulter son compte.


Toutefois si vraiment vous affectionnez la photo, je pense qu'il pourrait utile de se pencher sur la reconnaissance des caractères mais cette solution me paraît fort compliquée et peu fiable. Voici pour répondre concrètement à vos questions:
kevinlourenco a écrit :
Comment savoir si un utilisateur à déjà envoyé cette addition ?
OCR + comparaison BDD

kevinlourenco a écrit :
Comment savoir si un utilisateur ne "photoshop" tout simplement pas ces additions pour changer cet id ?
Aucun moyen au moment de l'upload. Mais la comparaison avec la BDD devrait retourner un résultat négatif si c'est le cas.

kevinlourenco a écrit :
Oui, mais et si la personne photoshop l'image et le met directement sur son portable ?
Je ne vois pas en quoi ce point vous inquiète. A la limite le client est libre d'utiliser le matériel qu'il souhaite. Qui dit qu'il n'a pas utilisé son portable pour prendre la photo ? Ou un camescope ou... Vous voyez où je veux en venir ?!

kevinlourenco a écrit :
s'assurer qu'il s'agisse bien d'une photo prise dans l'instantané
L'instantané est un impératif ? J'imagine bien le tableau : soirée picole, grosse flemme. Bon bah je prendrais la photo demain quand j'aurais cuvé Smiley cligne
Et puis ? Ca change quoi dans le principe de fidélisation ?!

kevinlourenco a écrit :
<input type="file" accept="image/*" capture="camera">
Du coup l'idée que je suggère en amont se gèrera par un simple <input type="text"> :-P

kevinlourenco a écrit :
Mais là encore les metas d'un JPEG peuvent être modifiés je me trompe ?
Comme toute donnée, oui c'est modifiable.

kevinlourenco a écrit :
Bonne soirée
La soirée fût bonne, bonne journée ! Smiley smile
Merci pour votre réponse,

Néanmoins ce n'est pas aussi simple, puisque ce n'est pas moi qui édite les tickets de caisse, je n'ai donc pas la main sur chacun d'entre eux et ne souhaite pas l'avoir non plus.

OCR + comparaison BDD

--> Trop gourmand en ressource, quand il y aura 1000 additions la bibliothèque GD va devoir tourner en boucle

Je ne vois pas en quoi ce point vous inquiète. A la limite le client est libre d'utiliser le matériel qu'il souhaite. Qui dit qu'il n'a pas utilisé son portable pour prendre la photo ? Ou un camescope ou... Vous voyez où je veux en venir ?!

--> Ba justement, si on s'assure que la photo soit prise sur le coup et par un appareil mobile, on réduit les chances de pouvoir modifier via photoshop d'éventuels éléments. Mais je vous l'accorde c'est assez contraignant au final.

Dans l'idée la solution qui apparait pourrait de mettre à disposition le restaurant de carte avec des codes inscrits dessus qui serait fournit au client pour récupérer ses points de fidélité. Il faudrait sensibiliser le client pour qu'il demande bien une carte en sachant que le restaurant est partenaire et faire en sorte d'avoir un stock assez conséquent de carte.

Merci de m'avoir aidé dans la réflexion, je ne voulais pas forcément impliquer le partenaire dans le processus mais cela semble impossible avec les photos des additions, mais je ne vois que ça au final.

Merci encore, je vais pouvoir débuter ma nuit tranquillement Smiley cligne

Bonne journée également Smiley smile
Modifié par kevinlourenco (16 Nov 2016 - 13:47)
Bonjour

Reflexion inverse Smiley smile

Si il s'agit d'un programme de fidélité auprès de certains restaurants Smiley smile
Je suppose que tu va prendre des accords avec les dits restaurants Smiley smile

La fourchette le fait déjà, il suffit que ce soit le restaurateur qui valide le montant sur ton application avec l'id du client Smiley cligne

Ainsi le process :
Ton client va dans un restaurant, il valide le programme de fidélité avec un id genre son num de client Smiley smile "bonjour, on va déjeuner et je participe au programme fideltruc numéro 525 Smiley cligne "

Le restaurateur va sur une plateforme internet simple Smiley smile qui lui est réservée (en gros c'est ouvert sur son navigateur dans sa caisse Smiley cligne (oui les caisses modernes vont sur internet Smiley cligne
Là il est dans son interface un clic sur nouveau client : entrez le code : 525, entrer le montant : 26,50€ valider.

Et voilà Smiley smile

rapide pour le restaurateur rapide pour le client et t'es sur qu'il n'y a pas de fraude.
Bonne idée j'avais déjà envisagé le model de lafourchette, mais cela pose d'autre problèmes, le principale étant la trop grande implication du client.

J'ai oublié de dire que nous nous lançons sur Paris et leur mentalité Smiley langue

Blague à part, ils sont noyés par toutes sortes d'offres, ce serait une erreur pour moi de devoir les obliger à faire une manoeuvre en plus dans leur métier. On en reparlera quand nous seront aussi réputés que LaFourchette Smiley cligne

Pour l'instant l'idée des cartes avec code me semble la meilleur solution, la seul contrainte apparente étant le vol, mais encore là, si le client réagit à l'avance, il est possible de "désactiver" les codes en question (ce n'est pas dans son intérêt de se faire voler puisque l'on prélève 1€ par client ramené)
Je travaille à paris, et je ne suis plus francilien depuis 7 ans, mais je n'ai pas de contrainte à utiliser la fourchette c'est quelque chose que je fais facilement Smiley smile

Pour l'exemple.
Il y a en place une petite application. les habitués pour la nommer.
CHiante à utiliser.
Je dois recharger mon compte, je dois donner mon email à l'endroit où ça marche, du coup je ne paye pas et je profite d'une réduc... bon pas mal mais chiant.
La boulangerie où je pourrais l'utiliser est super sympa et il doit rentrer l'email de la personne etc c'est contraignant, et pourtant avec 500 clients à l'heure (dans le 8 eme à midi Smiley cligne ) et bien il prend le temps de le faire...

Donc la contrainte dont tu parles n'existe pas...

Peu importe que tu sois connu ou non, le restaurateur va voir l'intérêt de la chose et surtout la simplicité du système.
L'intérêt : gagner des clients.
La simplicité : juste un code et un montant à valider.

C'est le comercial qui doit bien faire son boulot pour "vendre" la solution et les devs qui doivent simplifier au max la procédure pour le restaurant Smiley cligne
Désolée de te donner tord, mais j'ai déjà la certitude que cela seraient une contrainte pour certains clients puisque je suis moi-même aller sur le terrain pour en être conscient.

Puis je ne vois pas l'intérêt d'utiliser cette procédure alors que celle que j'ai énoncée est plus simple et moins contraignante pour le resto, donner une carte et basta.

Ca aurait été surement indispensable si je prenais un pourcentage par client, hors ici ce n'est pas le cas, la commission est fixe par client.

"C'est le commercial qui doit bien faire son boulot pour "vendre" la solution et les devs qui doivent simplifier au max la procédure pour le restaurant"

Je suis d'accord, mais pas dans ce sens, si une offre ne répond pas aux attentes clients, tu pourras avoir le meilleur commercial, cela n'y changera rien. C'est dans l'autre sens qu'il faut voir les choses : C'est aux devs de simplifier au max la procédure pour le restaurant pour que le commercial puisse bien faire son boulot.
Modérateur
Des cartes à code que le restaurateur donne lors de l'addition ça semble effectivement simple et efficace.
Pas trop de boulot de la part du restaurateur, mais il peut quand même vérifier qui est venu avec l'offre.

a écrit :
Merci de m'avoir aidé dans la réflexion, je ne voulais pas forcément impliquer le partenaire dans le processus mais cela semble impossible avec les photos des additions, mais je ne vois que ça au final.

Je suppose qu'un partenaire qui souscrit à ce genre d'offre veut être au courant, histoire de vérifier s'il ne se fait pas enfler.
Bonjour Kevinlourenco,
ce n'est pas aussi facile que Kusto le prévoit. Car sa piste de réflexion ouvre une boîte de pandore.

Hors d'un passeport biométrique, on ne peut pas voir comment un client aurait réglé voire délégué sa consommation ! En effet, un "clone" de facture pourra toujours s'y substituer aisément ...

Ou à consulter les comptes de paiement par carte bancaire ?

C'est toutefois légitime de déléguer une consommation (dont les clauses abusives des HyperMarchés Carrefour, Leclerc, LeroyMerlin, BricoMarché, ...) !

Maintenant, à défaut d'une confiance minimale en la société française, celle-ci s'écroule. Et faut-il l'envisager ?

Entretemps, vois mieux et davantage tes partenariats, car si des "clients" s'en reviennent chez toi, cela suffira de t'en satisfaire. Non ?

En conclusion : ne crains-tu pas qu'un Tribunal d'Instance up-to-date considère ta raison sociale qui soit vendre de la bouffe, fliquer des clients à leur insu. Et Bonjour la CNIL pour la gestion des fichiers informatiques de tes clients ... auprès de laquelle tu auras du te déclarer.

Et vu de mon côté, ce topique mérite de l'ivresse du pouvoir, peut-être d'une arnaque imbécile.
Modifié par pictural (17 Nov 2016 - 11:11)
Sujet clos
Aller à