Paul Jusot

Modèle conceptuel de données

Hiérarchie des noeuds

Tout tourne autour de l'entité  recursive "Node" qui a un rôle central. Elle décrit l'assemblage d'une page web à la manière du DOM mais en plus simple. Chaque entrée correspond à une partie du HTML.

Il devient possible de modifier la construction d'une page. Vous trouvez que le fil d'Ariane (breadcrumb) est inutile à côté du menu et vous préféreriez qu'il se trouve dans le pied de page? Remplacer juste son parent par le footer.

Noeuds communs et spécifiques à une page

Un noeud peut faire partie d'une ou d'aucune page (relation 0,1). Si le champ "page_id" vaut NULL, le noeud sera commun à toutes les pages (il s'agit de head, header, main, footer, nav et breadcrumb). Dans le cas contraire (blocs de page, articles), on le retrouvera en plusieurs exemplaires dans la table avec des données différentes. Je ne suis pas complètement satisfait de ce fonctionnement mais ça fonctionne.

Il y a une relation 1,1 entre Node et NodeData qui est justifiée par le fait que les données y ont des natures différentes. Node détermine l'assemblage du HTML et NodeData fait ce que son nom suggère. De la même manière, Article contient le contenu HTML des articles générés par TinyMCE et est reliéaux entrées post et news dans Node, un article est donc déplaçable et supprimer son noeud n'en supprime pas le contenu.

Le champ "position" dans Node permet de déterminer l'ordre d'affichage d'éléments de même parents. Tous les noeuds sont affectés par ce réglages à l'exception des articles de type "news" qui affichés par ordre chrono ou antichronologique. Le système de pagination fonctionne avec les deux manières d'order les articles.

Hiérarchie des pages

l'Entité Page est elle-aussi récursive. Deux classes utililitaires Menu et Path permettent: la première d'instancier les classes Page imbriquées qui serviront à générer le menu en lisant toutes les entrées pour lesquelles "in_menu" vaut 1 (c'est à dire la plupart), la seconde d'obtenir le chemin d'une page sous la forme d'un tableau PHP et d'une chaine de caractère (regardez dans la barre d'adresse).

Diagramme de classes

Droits d'un utilisateur de ma BDD

Le site des nageurs bigoudens utilise une base de données MySQL gérée par OVH. Il s'y connecte à l'aide de ses propres identifiants. Ce qui suit concerne ce portfolio qui est une autre instance du même site hébergée chez moi.

L'utilisateur "root" a tous les droits sur la base de données. Toutefois, il ne fonctionne que sur localhost et ne doit servir qu'à attribuer des droits à d'autres utilisateurs et à la résolution de problèmes.

L'utilisateur au nom caché sur la capture d'écran est utilisé par certains sites web hébergés sur mon serveur. Les droits attribués varient mais on y trouve généralement le CRUD: SELECT, INSERT, UPDATE, DELETE.

Il n'est accessible que sur localhost. Pour raison de sécurité, une application distante nécéssiterait la création d'un autre utilisateur.

Dissimulation des codes de connexion

Les codes de connexion ne doivent jamais figurer dans le code. Dans le cas contraire, ils sont retrouvables dès lors que le code source est placé sur un dépôt public comme Github.

La bonne pratique est de les placer dans un fichier spécifique situé hors du dossier racine de l'application et d'ajouter ce fichier au .gitignore pour qu'il ne soit pas ajouté au dépôt git par erreur.

Création d'hôtes virtuels Apache

Un certificat pour Mariadb

J'utilise le même certificat Let's encrypt que celui du serveur web. Lorsque je renouvèle le certificat, la BDD en donc bénéficie aussi.

Création d'un certificat let's encrypt pour le serveur Apache

Les fichiers sont placés ici: /etc/letsencrypt/live/mon-domaine/
Ils suffit de les mentionner là: /etc/mysql/mariadb.conf.d/50-server.cnf

Certificat de l'utilisateur?

Arrivé à cette étape, le serveur de refuse encore les connexions distantes parce qu'un certificat côté client est également attendu.
J'ai supprimé cette exigence contraignante (dans 50-client.cnf) en remarquant toutefois qu'il pourrait s'agir d'une défense très efficace dans le cas d'une BDD chiffrée liée à une application qui elle-seule possède les clés de déchiffrement (comme dans le sujet de BTS blanc de l'épreuve de cybersécurité de 2024).