Terrain 16 — Sécurité & qualité

require_login() garantit un utilisateur connecté et l’accès au cours/activité (visibilité, inscription, restrictions). Première ligne de toute page. Sans elle, l’accès est ouvert. Variantes : require_login() seul (contexte système).

require_capability($cap, $context) bloque si le droit manque dans ce contexte (terrain 11). require_login dit « connecté » ; require_capability dit « autorisé ». Les deux sont nécessaires. has_capability() renvoie un booléen pour un affichage conditionnel.

Le sesskey prouve que la requête vient de ton interface (pas d’un site tiers = CSRF). Toute action qui modifie un état via GET/POST hors Form API exige require_sesskey(), et le lien doit porter sesskey(). La Form API le gère automatiquement.

required_param/optional_param + un type PARAM (INT, ALPHA, TEXT, ALPHANUMEXT, RAW…) lisent et assainissent. On ne touche jamais $_GET/$_POST bruts. Le type est la première défense. RAW = non filtré (à éviter/échapper à la sortie).

Le DML paramètre les conditions → pas d’injection. Pour du SQL custom : $DB->get_records_sql($sql, $params) avec des placeholders (:id), jamais de concaténation. Privilégie l’API haut niveau (get_record(s), get_in_or_equal).

s() échappe un texte pour du HTML ; format_string() échappe et applique les filtres (pour les noms/titres). On échappe au moment de la sortie. Les templates Mustache échappent déjà {{var}} automatiquement (préfère-les).

format_text() nettoie le HTML (anti-XSS), applique filtres et gère les fichiers embarqués (via le contexte). Pour du contenu riche (intro, forum). ⚠️ Ne jamais afficher du HTML utilisateur sans format_text (ou s() pour du texte simple).

clean_param($value, PARAM_*) applique le filtrage d’un type PARAM à une valeur déjà en main (issue d’un calcul, d’un webservice). Complète required_param. Toujours typer les données douteuses.

echo $data->name avec <script>alert(1)</script> exécute le script (XSS). Correction : echo s($data->name). Fais-le en local : voir la faille tirer ancre le réflexe d’échappement bien mieux que la théorie.

Sans sesskey, un site tiers peut déclencher une suppression au nom d’un enseignant connecté (CSRF). require_sesskey() casse l’attaque (l’attaquant ne peut pas deviner le jeton). D’où : jamais d’action d’état sans sesskey (ou via Form API).

Servir un fichier passe par un callback *_pluginfile() qui vérifie login + capability + contexte avant de délivrer le fichier (via send_stored_file). Sinon, fuite de documents privés. La File API sécurise l’accès aux fichiers stockés (Partie 5).

Tout plugin stockant des données perso doit un classes/privacy/provider.php : déclarer les données (get_metadata), les exporter (export_user_data) et les supprimer (delete_data_for_user). Sans lui, install signalée non conforme → refus wp… pardon, moodle.org (Partie 11).

Aucune chaîne visible en dur : tout via get_string() + lang/en/. C’est de l’i18n ET une exigence de qualité (le codechecker le vérifie). Un texte non traduisible = un plugin non publiable. (Côté JS : core/str, terrain 14.)

Chaque fichier PHP porte l’en-tête GPL standard + PHPDoc (@package, @copyright, @license). Le générateur de squelette (terrain 12) les met. Exigé par le coding style et la review. Forme = signal de sérieux.

moodle-cs (PHP_CodeSniffer) vérifie indentation, nommage, PHPDoc, fonctions interdites, patterns de sécurité. Vise zéro erreur. À lancer en continu (VS Code/CI), pas à la fin. C’est le juge de forme de moodle.org.

Un test étend advanced_testcase, utilise $this->getDataGenerator() pour créer cours/users/instances, et assert le comportement. $this->resetAfterTest(). Lancé avec vendor/bin/phpunit. Filet contre les régressions (terrain 12, jeu 20).

Behat décrit le parcours en langage Given/When/Then (Gherkin), joué dans un navigateur. Vérifie l’UX de bout en bout (l’étudiant coche → la note apparaît). Lourd mais précieux pour un mod. Lancé via l’environnement Behat (terrain 12).

Le frankenstyle (local_todolist_, mod_simplecheck_) évite les collisions avec le cœur et les autres plugins. Fonctions globales, tables, options, capabilities, événements : tout préfixé. Une fonction save() non préfixée casserait potentiellement le site.

Jamais de core hack (chaque MAJ l’écraserait, et c’est un risque de sécurité). On passe par hooks/callbacks, un plugin du bon type, ou une surcharge propre. Si vraiment impossible, on propose un patch au cœur (Partie 11). Tout est faisable par plugin.

Si tu coches tout, tes plugins sont sûrs et publiables. Ces réflexes sont exactement ce que traque la review moodle.org (Partie 11). La sécurité/qualité n’est pas une étape finale : c’est une façon d’écrire chaque ligne. Cap sur l’ouverture vers l’extérieur : les web services (terrain 17).