Quiz 4 — Web services & LTI

execute_parameters() (types d’entrée), execute() (logique), execute_returns() (type de sortie). Le contrat typé de l’endpoint, dans classes/external/.

À typer et valider les entrées avant ton code (external_value(PARAM_INT, …)). Comme un schéma zod : entrée invalide → rejet automatique.

Parce que les web services contournent l’UI mais pas les permissions. On reproduit les vérifications de contexte et de capability, sinon fuite de données. Point critique.

Il déclare la fonction (nom public frankenstyle, classe/méthode, type read/write, capability requise). Sans cette déclaration, la fonction n’existe pas pour l’API.

Une clé d’authentification portant les droits d’un compte de service. Il doit rester côté serveur (jamais dans le navigateur) et suivre le moindre privilège.

Administration → Serveur → Web services : activer le protocole REST, créer un service externe, y ajouter des fonctions, créer un token. L’assistant « Vue d’ensemble » déroule tout.

À demander une réponse JSON (plutôt que XML) sur webservice/rest/server.php. Avec wstoken et wsfunction, c’est le trio minimal d’un appel REST.

Une liste typée (souvent d’objets external_single_structure). Le cas le plus courant : renvoyer une liste de cours, de participants… Moodle valide chaque élément.

Les web services (un service prédéfini). C’est la même porte d’intégration que ton front Next.js headless — d’où l’importance de bien concevoir ses external functions.

Les mêmes external functions servent l’Ajax interne (via core/ajax, avec la session) et les WS externes (avec token). Une fonction bien faite sert les deux mondes.

La plateforme (le LMS, ici Moodle) lance un outil externe (ex. QuizLab). L’outil s’affiche intégré, connaît le contexte et peut renvoyer une note.

mod_lti = Moodle consomme un outil externe (plateforme). enrol/lti = Moodle publie une activité comme outil pour un autre LMS (Moodle = outil). Le protocole est symétrique.

Sur OIDC + JWT (OAuth2). Le launch envoie un id_token (JWT signé) portant identité et contexte, que l’outil doit valider.

La signature (via JWKS de la plateforme), iss, aud, exp, le nonce (anti-rejeu) et le deployment_id. Sauter une vérification = faille exploitable.

Assignment & Grade Services : l’outil crée une line item et renvoie le score dans le carnet de notes du LMS (grade passback), via un appel REST authentifié.

Un flux où l’enseignant, depuis le LMS, ouvre l’outil pour choisir/configurer un contenu (ex. un quiz précis) qui revient s’insérer comme activité.

Names and Role Provisioning Services : l’outil récupère la liste des inscrits et leurs rôles — pour un tableau de bord enseignant. Le 3e service de LTI Advantage.

JWKS = les clés publiques pour vérifier les signatures ; client id identifie l’outil auprès de la plateforme ; deployment id identifie un déploiement précis. Socle de confiance du launch.

Parce qu’il porte des droits : exposé au navigateur, il serait volé. Tous les appels (WS ou AGS) passent par le serveur (Next.js), jamais depuis le bundle client.

Parce que le même outil (config par plateforme) sert N LMS compatibles (Moodle A, B, Canvas…) : 1 outil, N clients. C’est la portabilité qui en fait un micro-SaaS revendable (Partie 13).