403

Niveau intermédiaire

Drupal : erreur 403 après une mise à jour de module

Votre site Drupal renvoie Accès refusé sur des pages qui marchaient hier ? Après une mise à jour c'est une permission ou un cache, pas un piratage.

Vous mettez un module à jour, et des pages qui s'affichaient hier renvoient « Accès refusé ». Parfois tout le site, parfois seulement l'administration, parfois seulement pour les visiteurs non connectés.

Le premier réflexe est de penser à une intrusion. C'est presque toujours faux : un 403 après mise à jour est un problème de permissions ou de cache.

Ce que 403 veut dire, et ce que ça exclut

403 signifie que le serveur a compris la demande, a identifié le demandeur, et refuse volontairement. C'est un refus, pas une panne.

Cela exclut d'emblée les erreurs de code, les problèmes de base de données et les pannes de serveur : ceux-là produisent des 500, pas des 403. Le site fonctionne, il vous dit simplement que vous n'avez pas le droit.

Les quatre causes, dans l'ordre

1. Une permission nouvelle, non accordée. C'est la première. Quand un module introduit une permission dans une nouvelle version, Drupal ne l'accorde à personne par défaut, y compris aux rôles qui avaient tous les droits avant. La page qui s'affichait hier exige aujourd'hui une permission que plus personne ne possède.

Direction Personnes puis Permissions, filtrez sur le module mis à jour, et regardez ce qui est décoché.

2. Un cache de routeur périmé. Drupal garde en cache la table des routes et leurs règles d'accès. Après une mise à jour, une route peut pointer vers une règle qui n'existe plus, et le contrôle d'accès échoue par défaut, donc en refusant.

drush cr

Faites-le avant toute autre investigation. C'est trente secondes, et cela résout un cas sur trois.

3. Le rôle anonyme a perdu « Voir le contenu publié ». Symptôme caractéristique : le site marche parfaitement quand vous êtes connecté, et renvoie 403 en navigation privée. Cette permission, access content, est parfois réinitialisée par une mise à jour de configuration.

4. Un .htaccess remplacé. Une mise à jour du cœur réécrit le .htaccess à la racine. Si vous y aviez ajouté des règles, elles disparaissent ; si le fichier livré est incompatible avec la configuration du serveur, Apache refuse l'accès. Là, le 403 vient du serveur et non de Drupal : rien n'apparaît dans le journal Drupal, et c'est justement le signe distinctif.

Le test qui sépare Drupal du serveur

Regardez /admin/reports/dblog.

• Une entrée « access denied » y apparaît : c'est Drupal qui refuse. Cause 1, 2 ou 3.
• Rien du tout : la demande n'a jamais atteint Drupal. C'est Apache. Cause 4, et la réponse est dans le journal d'erreurs du serveur.

Cette distinction en dix secondes vous évite de chercher une heure du mauvais côté.

L'ordre de dépannage

1. drush cr, et rechargez.
2. Testez en navigation privée pour distinguer un problème de rôle anonyme.
3. Ouvrez le journal Drupal et regardez si le refus y figure.
4. Comparez les permissions du module mis à jour avec ce qu'elles étaient.
5. Vérifiez /update.php : une mise à jour de base non appliquée laisse la configuration à moitié migrée.
6. Si le journal est muet, allez lire le journal du serveur.

Ce qu'il ne faut pas faire

Ne donnez pas toutes les permissions à tous les rôles pour « voir si ça revient ». Vous ouvrirez le site en grand, vous perdrez la trace de la configuration d'origine, et vous ne saurez toujours pas quelle permission manquait.

Ne réinstallez pas le module. Une désinstallation supprime souvent ses données de configuration, et vous transformerez un problème de permission en perte de contenu.

Si l'erreur persiste après le cache et les permissions, il reste une piste : une mise à jour de base non exécutée. Décrivez-moi le symptôme, le diagnostic est gratuit.