Validations Générales d'un site

J'essai tant bien que mal de comprendre la demande, mais c'est plutôt avec du mal.

La validation et la sécurisation sont deux choses différentes.

La validation c'est définir des règles dans les Models qui indiquent que tel champ doit être de tel ou tel type, que telle donnée est obligatoire, ou doit être dans un certain format, etc.

Tout ça, c'est un traitement à faire avant l'enregistrement en BDD.

La sécurité, c'est tout autre chose. Il faut évidemment se prémunir contre le hack pur et simple, mais également contre le bruteforce, contre les injections, contre les dénis de service, et tout un tas d'autres failles potentielles.

Par ailleurs, dans le cas de l'e-commerce, les input client sont souvent négligés.
Il peut être judicieux de gérer toute la partie panier, tunnel de paiement, etc en session plutôt que de faire confiance aux simples formulaires ou données affichées, ceci afin d'éviter que l'utilisateur ne modifie lui même le montant de son panier et valide une commande de 1000€ pour 10€.

Qui dit e-commerce dit aussi SSL, c'est donc une surcouche de sécurité supplémentaire à mettre en place à minima sur tout le tunnel de paiement, mais dans l'absolu sur l'ensemble du site.

Un tutoriel qui couvre tout ça est impossible à concevoir, dans la mesure où il durerait probablement 72 heures, mais également parce que sécuriser l'ensemble d'un site n'est pas qu'une affaire de développement, c'est aussi de la Sys Admin, de l'algo, du cryptage, etc.

Assez d'accord avec Pakito.
La sécurisation d'une appli de ce type ne se restreint pas à avoir un panier en session et à vérifier l'intégrité des champs entrés par l'utilisateur. Ca va bien plus loin que ça.

Et je pense que passer par un MVC maison pour ce genre d'application, c'est un peu reconstruire une grue depuis zéro à la main à chaque fois qu'un nouvel immeuble doit être bâti.

Bonjour, et surtout merci de vos réponses qui m'éclaire en même temps.

En effet, je parle pas de la validation mais vraiment de la sécurité coté serveur et php.

J'ai bien vu qu'il y a des tuto sur grafikart qui porte un peu sur le sujet. Mais je cherche quelque chose d'un peu plus poussé. J'ai proposé cette idée car je trouve qu'a notre période on doit vraiment penssé à la sécurité que ce soit coté back office mais aussi front office et surtout pour rassuré un client ou un visiteur sur le fait qu'un site est bien protégé et qu'il n'a pas de crainte à avoir.

Du coup, je connais pas trop le SSL, mais je comptais le faire. Si vous connaissé un bon site ou je peux me renseigner sur ça, je suis prenneur. Par contre, sysAdmin ne me dit rien fu tout, je vais chercher un peu ce que c'est.

En tout cas un grand merci pour vos réponse. J'espère que grafikart pourra devellopper un tuto un peu plus pousser sur ce sujet la.

Desole, je viens de m'appercevoir que j'ai 2 comptes grafikart. Du coup je vais en supprimmer un. Mais jim449 c'est bien moi. :)

Juste pour rebondir sur un point évoqué par Rizerzero, même si je suis d'accord avec l'ensemble du discours des un et des autres :
"la validation ce n'est pas que dans les models sous laravel ca passe plutot dans les controllers et je trouve ca plus naturel car c'est de la logique donc =>Controller"

C'est là qu'est le souci, pour y être confronté en ce moment avec plusieurs clients, notamment dans tout ce qui est financement (banque, crédit, etc.), je pense qu'il faut respecter un tant soit peu et la logique du MVC, et également l'optimisation.

Quand je parle de validate dans les Models, c'est parce qu'ils s'agit là de règles fixes, qui s'appliqueront à tout le Model, que ce soit lors d'un create, d'un update ou d'un select.

On peut aujourd'hui faire des choses énormes comme ceci, en pensant de façon intelligente les callbacks sur les before/after Filter, Find, Save, etc.

En revanche, quand il s'agit d'une règle ultra spécifique qui ne va s'appliquer qu'à une seule méthode de la classe, alors à ce moment là oui, la logique doit être implémentée dans la méthode elle même.

Ca évite d'une part de dupliquer son code, d'autre part de vérifier des tas de paramètres dans une méthode et de zapper de le faire dans une autre.

Je bosse bien souvent avec Cake ou avec Rails parce qu'il respectent cette logique. Je me suis essayé à Zend, Symphony, Laravel et d'autres, et c'est cette interprétation, erronnée à mon sens, de là de la logique MVC qui m'en a détourné.

Mais tout ceci ne relève pas vraiment de la sécurité stricto-sensu, donc je vais arrêter là le hors sujet, mais dans le cas de l'e-commerce, avoir des models robustent, vu le nombre de liaisons qui existe en général, c'est un point indispensable.

@usora sysAdmin c'est administrateur système ,{installation réseaux , windows , linux , routages [cisco], serveurs ect...]

@Pakito , oui d'un point de vue sécurité comme tu dis si on prend la peine de faire une validation niveau model pour être certain de la validité d'un transaction finassière la je te suis complètement je serais plus rassurer de mettre un FilterBefore meme si j'ai déjà un code qui assure cette validité dans le controller quitte a dupliquer le code de validation ou a utiliser des traits pour utiliser les méthodes de validation ici et la mais en fait le faite qu'elle soient distincte apporte un avantage {si l'un a été modifié par erreur et flanche reste l'autre } mais l'inconvénient reste la maintenabilité ,
mais bon comme tus dis on s'écarte du sujet .