Site e-commerce

Merci de ta réponse !

Pour le password, tu compte utiliser quel méthode de chiffrement ?

J'utilise MD5 donc c'est bien 32 caractères je crois ! Pareil pour le token

Et sinon concernant la colonee MPL_Valid, étant donné que je n'ai besoin que de 0 ou 1, le type le mieux adapté est INT(2) ? Ou alors je coche Binary colonne ? D'ailleurs j'ai tout mis en NNul, ais-je bien fait ?

Autre chose, je pense qu'avant de continuer à coder le front-office je devrais commencer/finir le back, comme ça je serait tranquille. Pour rappel, je devais faire le site sous une architecture MVC. J'ai fais simple, voici mon Dispatcher principal, mon index principal en gros.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?php 
include_once("config/config.inc.php");
include_once("modele/param.inc.php"); 

if (!isset($_GET["module"])) {
    $module = "page";
} else {
    $module = $_GET["module"];
}

if (!isset($_GET["action"])) {
    $action = "index";
} else {
    $action = $_GET["action"];
}

$url = "controleur/". $module ."/". $action .".php";

if (file_exists($url)) {
    include_once($url);
} else {
    include_once("vue/404.php");
}

Seulement je suis embêté, car je vois pas comment faire si je veux accéder à mon back-office avec comme url : monpanierlivre/admin.php.... En gros je créer un dossier Admin à la racine et je me débrouille avec des header:location, mais du coup cette partie ne sera pas vraiment M-V-C ? :/

Avez-vous une idée ?

J'utilise MD5 donc c'est bien 32 caractères je crois ! Pareil pour le token

oO, pas cool, sha512 minimum !

Est-ce vraiment raisonnable ? Dans le cadre de ce projet je pense que le md5 suffit. C'est juste histoire de pas avoir en dur les mdp dans la base.

Et pourquoi ne pas prendre dés maintenant les bonnes habitudes ?

Est-ce vraiment raisonnable ? Dans le cadre de ce projet je pense que le md5 suffit. C'est juste histoire de pas avoir en dur les mdp dans la base

Dans le cadre d'un projet scolaire, faire l'erreur puis la corriger fait partie des objectifs avoués des enseignants. Je dis ça, je dis rien.

D'accord, d'accord, je vais suivre votre conseil alors Je pensais qu'à la limite un sha1 avec un grain de sel aurait pu suffire largement, surtout que le sha512 doit pomper pas mal de ressource.

Allez ! Je pars pour le sha512, faut bien une première à tout !

Si je peux justifier mon choix comme tu viens de le faire c'est génial. Au moins si à la soutenance il me pose la question je saurais me défendre

Merci!

Cependant, à titre d'information, un exemple comme celui-ci (mélange des deux) peut-il suffire, avec à la limite un grain de sel en plus, à sécuriser suffisamment les mots de passes pour un site e-commerce ?

1
2
3

<?php
$hash=md5(sha1($mdp));
?>

J'ai pas vraiment le courage de détailler

C'est déjà très gentils de votre part de consacrer votre temps !

Merci pour ces remarques, je comprends un peu mieux maintenant ces histoires de hashages. Concernant le code postal, je ne gère que la France. Mais pour gérer ceux qui commencent par 0, le mieux est de mettre un char alors ?

Si ton site est consacré uniquement à la France (et pas la francophonie), un char(5) fait très bien l'affaire. Ça te gère les 0 sans rien avoir à faire.

Bonsoir !

Histoire de partager mon code plus facilement, je teste GitHub (je dois sûrement mal l'utiliser encore !)

Mon projet

J'ai une page d'accueil pour l'instant qui fonctionne sous un modèle MVC simple. Je pense que concevoir le back-office avant toute chose serait une bien meilleure idée, plutôt que continuer à coder le panier ou l'espace client. En effet, une fois "débarrassé" je pourrais me concentrer sur le reste

Je viens vous voir pour discuter avec vous de quelle manière je pourrais architecturer la partie admin : une solution auquel j'ai pensé était de créer un dossier admin à la racine avec lui même sa structure MVC à l'intérieur, c'est à dire avec son dispatcher principal, ses modèles et tout. Est-ce une bonne idée ?

Je ne dois avoir assez de recul et l'histoire des SESSIONs me rebute un peu. En gros j'aimerais que lorsque l'on tape : monpanierlivre/admin , on arrive sur un formulaire.

Autre chose : si je souhaite développer une sorte de Dashboard pour le back, je me lance dans quelque chose de compliqué ? C'est pas la facilité que je cherche mais le temps passe vite

Sans utiliser de SESSIONs, je donne pas cher de la sécurité de ton site…c'est le strict minimum, la base des bases.... tu devra d'ailleurs aussi apprendre à les utiliser pour gérer le panier de tes clients, la connexion de ceux-ci…tu ne peut/doit pas tout gérer avec des COOKIEs.

Ah non qu'on soit bien d'accord, j'utilise les SESSIONS ! Je disais juste que je m’emmêlais vite les pinceaux avec. J'ai commencé à développer un peu le panier et la création de compte. Et j'utilise bien les SESSIONS

En gros en ce qui concerne la création/validation de compte je procède comme suis :

On créer un enregistrement dans la table avec une clef et un code de validation à 0. On transmet ensuite le mail avec la clef sous forme de lien cliquable. L’internaute clique, renvoie la clef, et grâce à cette clef, on vient modifier l’indicateur dans la colonne de validité pour que le compte devienne utilisable.

Mais j'ai laissé de côté mes bouts de code, voulant me pencher sur le BackOffice (le finir avant de continuer le reste en faite).

Pour Github renomme le Lisez-moi.txt en README.md.

J'ai jeté un coups d’œil tu n'as pas encore de page "complète/fonctionnelle" (MVC) ?

Peut-être commencer à utiliser les namespaces, si tu n'utilises pas de classe. Et ce qui est bien c'est le chargement auto spl_autoload_register(), Ici c'est celui que Symfony intégre (sans devoir utiliser d'include).

L'idée serait de faire par exemple :

1
2
3
4
5
6
7
8
9

<?php
/* monpanierlivre/controleur/page/index.php */
namespace controleur\page\index;

include("abc.php");
use modele\page\index; // = include_once("modele/page/index.php");
// ou directement : `modele\page\index\affichage` pour juste avoir à faire `affichage();`

index\affichage();

1
2
3
4
5
6
7

<?php
/* monpanierlivre/modele/page/index.php */
namespace modele\page\index;

function affichage() {
    echo "<pre>modele\page\index\affichage()</pre>";
}

Pour les namespaces tu peux trouver la doc ici : Règles de résolutions de noms, il suffit de 20 minutes pour intégrer le principe des use abc, namespace abc, abc\mafonction(), new \PDO().

Pour le Dashboard (Tableau de bord), tout dépend que tu souhaites faire, des requêtes SELECT COUNT peuvent suffire, ou bien tu devras rajouter des "logs" dans une autre table.

Je te remercie A-312 d'avoir répondu Je vais me pencher sur les Namespaces, ça à l'air super intéressant !

Tu me demandais si j'avais pas de page complète/fonctionnelle en MVC. J'en ai fait une, cependant le visuel est dégueulasse et j'ai encore des p'tits problèmes. C'est l'inscription / connexion des utilisateurs.

J'ai pas tout finis, il y a des choses je vois pas trop comment faire : par exemple dans modele/user/connexion.php J'ai fais un query->fetch(PDO::FETCH_ASSOC); pour récupérer des informations dans mes SESSIONS (pseudo, images, …) pour les réutiliser dans d'autres pages comme sur la page perso, dans le header etc… Mais je vois pas comment m'y prendre.

Il faut aussi que je gère les formulaires (avant le submit), je me suis penché sur les Filtres PHP (le tuto de ce site) mais je voulais vous consulter avant, c'est une bonne solution ?

Projet sources

Visu

les filtres en PHP interviendront après le [submit], il existe de multiple solutions pour vérifier les champs avant le [submit], mais ceux-ci ne doivent jamais être utilisé en substitution des vérifs PHP (d'ailleurs, ces solution sont à considérer comme user friendly, pas comme des vérifs) :

• Le type du champ : les navigateurs aident de plus en plus les visiteurs en lui indiquant (grâce au type de champ employé, si le champ contient bien le type attendu, et bloque le submit dans le cas contraire)
• Javascript : il permet de d'obtenir à peu près le même résultat, mais en affinant au cas par cas tes champs
• Ajax : liaison en direct entre le javascript et le PHP, il peut te permettre de transmettre en direct les infos remplis dans un champs vers un fichier PHP qui lui se chargera de pré-vérifier les champs

Je préfère me répéter une seconde fois, AUCUNES DE CES SOLUTIONS NE PERMETTRA DE VÉRIFIER CONVENABLEMENT LA VALIDITÉ DES INFORMATIONS CONTENUES DANS LES CHAMPS DE TON FORMULAIRE !!

Comme on dit "Never Trust User"

Ok, je vais essayer de faire un truc propre alors, j'te remercie babas !

Mais sinon concernant ma fonction d'identification (connexion) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

<?php
function identification($login, $pwd){
    global $pdo;
    try {
        $query = $pdo->prepare("SELECT * 
            FROM MPL_Users
            WHERE MPL_Pseudo ='$login'
            AND MPL_Password ='$pwd'
            AND MPL_Valid =1");
        $query->bindValue(':login', $login, PDO::PARAM_STR);
        $query->bindValue(':pwd', $pwd, PDO::PARAM_STR);
        $query->execute();
        $row = $query->fetch(PDO::FETCH_ASSOC);
    }
    catch( PDOException $e ) {
        die('Erreur Mysql : '.$e->getMessage());
    }
    return $row;
    $query->closeCursor();
}

En faite je voudrais remonter les informations de l'utilisateur dans la SESSION, pour pouvoir m'en resservir dans les autres pages. Avez-vous une idée de comment procéder ? je pense qu'un FETCH_ASSOC (sous forme de tableau associatif) pourrait être une solution mais je vois pas comment ensuite "utiliser" les informations que je veux.

Hey, je reviens vous voir pour essayer de finir ma base ! Elle est particulièrement maigre pour l'instant donc j'aimerais avoir des conseils sur ce qu'il me reste à faire.

Ma base de donnée

Pour les relations entres les tables je n'ai pour l'instant trouvé que Produit<–>Catégorie, sachant qu'un produit peut être compris dans plusieurs catégories.

Il faudrait que je gère aussi le système de "promotion" sous forme de pourcentage (ou valeur fixe ?) à partir de mon Back-Office. Comment gérer ce point côté base ?

Ou encore la gestion des stocks ? De mon back office, si je veux augmenter ou diminuer la quantité d'un produit.

J'aimerais aussi gérer le tout en cascade, c'est à dire si je supprime une catégorie, que ça supprime aussi les produits à l'intérieur.

Si vous voyez d'autres choses, n'hésitez pas Merci d'avances !

Bonsoir !

J'ai fini globalement la base de donnée ! Il reste cependant un p'tit point où je bloque : toujours ce système de promotion. Si du back office je veux pouvoir faire une remise en pourcentage sur une certaine catégorie de produit, comment je dois faire ça côté base ?

Je créer une nouvelle table "promo" que je relis à produit ? A catégorie ? Pour le coup j'arrive pas trop à trouver une solution..

Ma base actuellement

Je vous remercie d'avance !

Salut !

J'ai essayé de regarder comment c'est géré dans Prestashop, mais c'est assez complexe. Cependant, il semble que les promotions sont liées à diverses choses, mais surtout à un produit.
OpenCart ne lie apparemment qu'à un produit.
J'aurais bien regardé dans Magento, mais il faut s'enregistrer pour la version communautaire, sinon payer…

En conséquence, je pense que lier ta table MPL_Promo à un article pourrait probablement te suffire