Définir la durée attendue et le type de poste
Une équipe peut utiliser WordPress depuis un poste d’accueil ou un ordinateur partagé entre plusieurs personnes. Dans ce contexte, une session durable peut rester disponible après le départ du rédacteur. Définissez avec le propriétaire la durée acceptable d’une nouvelle connexion, le comportement attendu à la fermeture du navigateur et la procédure de déconnexion en fin de travail. Le réglage doit correspondre aux usages réels, notamment aux longues périodes de rédaction ou de préparation d’une commande.
Distinguez une durée depuis la connexion d’un délai après inactivité. Le filtre du cœur auth_cookie_expiration règle une durée liée aux cookies émis. Si le besoin porte sur l’inactivité, demandez un mécanisme qui mesure cette inactivité et documente ce qu’il considère comme une action. Une page ouverte, des requêtes de fond ou un éditeur qui sauvegarde automatiquement peuvent rendre cette notion différente de celle attendue par l’équipe.
Relevez les accès qui utilisent le formulaire WordPress et ceux qui passent par une connexion unique ou un service externe. Ce dernier peut réauthentifier l’utilisateur selon sa propre session. Une durée modifiée dans WordPress doit donc être observée de bout en bout sur le parcours réellement utilisé.
Relever le comportement actuel avec un compte d’essai
Préparez un compte d’essai doté des permissions nécessaires au test. Relevez l’heure d’une connexion sans l’option Se souvenir de moi, puis celle d’une connexion séparée avec cette option. Utilisez des profils de navigateur distincts pour éviter de mélanger les cookies. Notez la version du navigateur et les réglages de restauration des onglets ou de conservation de session. La fermeture visuelle de la fenêtre ne garantit pas toujours le traitement des cookies que l’équipe imagine.
Dans le code documenté de WordPress, le choix de mémorisation influence la durée utilisée et la persistance du cookie. Le projet peut filtrer cette durée. Demandez au mainteneur si une extension de sécurité, une règle interne ou un service d’authentification modifie déjà le résultat. Le nom du filtre dans un fichier constitue un indice, mais sa présence ne suffit pas à connaître la priorité des callbacks et leur valeur finale.
Relevez aussi ce que voit un rédacteur quand sa session expire. Une demande de reconnexion pendant un brouillon doit être traitée dans la recette, avec un document de démonstration. Évitez de tester une limite courte sur un travail réel qui n’a pas encore été sauvegardé.
Choisir une politique que l’équipe peut expliquer
Un exemple de politique consiste à limiter toutes les nouvelles sessions WordPress à deux heures sur l’installation concernée, même si l’utilisateur coche la mémorisation. Un autre projet peut vouloir une durée différente selon le mode choisi. Faites valider les valeurs et leur périmètre avant de toucher au code. Pour des rôles particuliers, confirmez comment la règle identifie les comptes et ce qui doit se passer si leur rôle change.
La durée doit laisser le temps de réaliser les opérations habituelles. Une période trop courte peut provoquer des reconnexions répétées dans les formulaires et inciter les utilisateurs à partager un accès de secours. Choisissez des scénarios de recette avec une action courte, une rédaction longue et un parcours qui revient sur une page après attente. Notez le résultat attendu pour chacun. Une politique de sessions doit rester compatible avec la procédure d’enregistrement du travail.
Définissez séparément la fermeture des sessions déjà ouvertes si elle est requise. Modifier le filtre utilisé lors de l’émission des cookies ne signifie pas que tous les anciens cookies ont reçu une nouvelle échéance. Si une fermeture immédiate est nécessaire, attribuez son mécanisme et son impact dans le plan d’intervention.
Préparer la configuration et l’accès de retour
Identifiez où le projet gère les règles d’authentification. Une extension dédiée du projet ou une extension obligatoire peut porter le filtre. L’emplacement doit être versionné ou documenté et rester accessible par le canal de déploiement de l’équipe. Si le fournisseur gère cette politique, demandez la valeur et la portée qu’il peut appliquer. Ne superposez pas un second filtre sans inventorier les règles existantes, car leur ordre peut modifier le résultat.
Conservez la version précédente du fichier et les valeurs attendues dans le dossier privé. Vérifiez un accès d’hébergement qui permet de remettre un fichier valide si une erreur PHP empêche la connexion. L’accès de secours doit appartenir à une personne habilitée et rester utilisable indépendamment de la session qui sert au contrôle. Évitez de compter uniquement sur l’éditeur de fichiers de WordPress pour corriger un problème d’authentification.
Sur une copie isolée, vérifiez aussi l’heure du serveur et du poste utilisés pour observer les échéances. Une dérive peut compliquer l’interprétation. Relevez le type d’environnement et le numéro de déploiement afin de ne pas attribuer à la production un test réalisé uniquement sur la recette.
Appliquer une durée explicite sur une copie
Dans un projet qui utilise le mécanisme standard du cœur, le filtre suivant fournit une durée de deux heures pour les cookies qu’il concerne. L’exemple s’applique globalement à l’installation et conserve le même résultat quel que soit le choix de mémorisation. Il illustre une politique validée pour un poste partagé, à adapter seulement après avoir défini les usages. Il ne mesure pas les périodes d’inactivité.
Placez le code dans le composant de configuration du projet ou dans un fichier PHP d’extension obligatoire prévu pour cette copie. Validez sa syntaxe avant chargement et confirmez qu’aucun autre callback ne remplace ensuite cette valeur. Si le projet possède déjà une règle, modifiez sa source plutôt que d’ajouter une définition parallèle. Dans un réseau, demandez au responsable de confirmer si le même réglage doit viser tous les sites de l’installation.
Après déploiement, créez une nouvelle session d’essai. Une session ouverte avant le changement ne constitue pas la preuve que le nouveau filtre a été appliqué. Relevez son heure de départ et la version du code chargée. Gardez l’ancien paquet prêt à être remis si la copie ne démarre plus ou si le parcours de connexion échoue.
Sur une installation standard qui n’a pas déjà ce filtre, un emplacement concret est wp-content/mu-plugins/atelier-session-duration.php. Placez le fichier PHP directement dans mu-plugins : un sous-dossier ne sera pas chargé automatiquement sans chargeur. Si WPMU_PLUGIN_DIR a été personnalisé, utilisez le répertoire effectif du projet. Dans Extensions, la section des extensions indispensables permet de repérer le composant. Pour revenir à l’état précédent, retirez uniquement ce fichier ajouté, ou restaurez uniquement la modification faite au composant existant ; conservez les autres extensions obligatoires, qui peuvent appartenir à l’hébergeur.
<?php
add_filter( 'auth_cookie_expiration', function ( $duration, $user_id, $remember ) {
return 2 * HOUR_IN_SECONDS;
}, 10, 3 );Observer les deux modes de connexion jusqu’à l’échéance
Ouvrez deux profils d’essai, l’un avec mémorisation et l’autre sans. Connectez-les après le changement, puis effectuez une action d’administration de démonstration au début et à proximité de l’échéance prévue. Après la durée, rechargez une page d’administration qui nécessite l’authentification et relevez le résultat. Le navigateur peut encore afficher du contenu déjà chargé. Une page restée visuellement ouverte ne prouve donc pas que la session est encore acceptée pour une nouvelle requête.
Le mécanisme de validation du cœur possède des comportements liés au contexte des requêtes, notamment pour certaines opérations POST ou AJAX. Les cookies de connexion et leur stockage ont aussi leurs propres règles. Évitez de promettre une déconnexion universelle à la seconde près à partir d’un seul test. Documentez les routes et modes effectivement observés, ainsi que le comportement de reconnexion. Une évaluation de sécurité qui exige un délai strict doit examiner ces détails avec le mainteneur.
Pour un formulaire en cours de rédaction, confirmez ce qui est conservé avant la demande de reconnexion et comment l’utilisateur reprend son travail. Une réussite sur une page de tableau de bord ne valide pas automatiquement le parcours de l’éditeur ou une interface métier fournie par une extension.
Contrôler la fermeture et la restauration du navigateur
Sur le poste de démonstration, fermez les fenêtres selon la procédure habituelle de l’équipe. Rouvrez le navigateur avec les mêmes paramètres que les postes partagés et demandez une nouvelle page d’administration. Relevez si le navigateur restaure sa session précédente. Les logiciels peuvent conserver ou restaurer les cookies de session selon leurs fonctions. La politique du poste et le mécanisme WordPress doivent donc être examinés ensemble.
Testez aussi le passage d’une personne à une autre. Le scénario doit prévoir une déconnexion explicite, une fermeture de session système ou un profil séparé selon l’organisation. Une durée maximale n’efface pas le risque d’une session ouverte pendant la période où elle reste valide. L’utilisateur doit disposer d’une action claire pour terminer son travail. Vérifiez que les personnes autorisées savent retrouver le bouton de déconnexion et confirmer le résultat sur une nouvelle requête.
Si le poste utilise un gestionnaire d’identité ou une connexion unique, répétez le parcours complet. Une session du fournisseur d’identité peut permettre une nouvelle connexion automatique à WordPress. Dans ce cas, le responsable de ce service doit confirmer la politique du poste partagé et les moyens de fermer la session qui réauthentifie l’utilisateur.
Traiter les sessions antérieures lorsque le plan l’exige
Si le propriétaire demande aussi la fermeture des sessions existantes, préparez une opération ciblée avec les outils autorisés du compte ou de l’administrateur. Les fonctions de session WordPress et les commandes WP-CLI correspondantes peuvent servir à inventorier et retirer des jetons selon le périmètre prévu. Vérifiez les utilisateurs visés et l’impact sur leurs travaux avant de lancer une destruction. La documentation de la commande choisie doit correspondre à la version disponible.
Un contrôle d’inventaire peut exposer des adresses réseau et des informations de session. Gardez ces données dans le dossier privé et limitez la collecte à ce qui est utile. Pour un utilisateur présent, prévenez-le de sauvegarder son travail et choisissez un moment convenu. Pour une session qui peut être compromise, appliquez le calendrier de l’incident décidé par le responsable. Une opération de fermeture et une nouvelle politique de durée ont des effets complémentaires.
Après retrait, vérifiez qu’un ancien navigateur doit se réauthentifier sur une nouvelle requête et qu’une nouvelle connexion autorisée fonctionne avec la durée prévue. Conservez la preuve sans copier de cookie dans le ticket ou dans un outil partagé.
Diagnostiquer une durée qui semble ignorée
Si une session nouvelle dépasse largement le comportement attendu, confirmez le déploiement, la présence du composant et les autres filtres qui peuvent intervenir. Vérifiez si le navigateur a réellement utilisé un nouveau cookie et si le parcours passe par le cœur standard ou une authentification personnalisée. Une extension peut remplacer une partie du mécanisme. Un utilisateur peut aussi avoir été réauthentifié sans formulaire visible par une connexion unique.
Si les connexions se ferment plus tôt que prévu, comparez les règles du fournisseur d’identité, du navigateur et des extensions de sécurité. Une durée configurée ne corrige pas un domaine de cookie incohérent, une horloge décalée ou une session supprimée ailleurs. Rapprochez les heures et les contextes avant de changer la valeur. Le contrôle d’une nouvelle requête aide à séparer un écran ancien d’une authentification encore acceptée.
Pour une différence entre deux frontaux, demandez les versions de configuration et la cohérence des paramètres d’authentification. Une politique mise à jour sur un seul serveur peut produire des observations variables. Corrigez la source de déploiement avant de conclure qu’un filtre ne fonctionne pas dans WordPress.
Revenir à la politique précédente et préserver la rédaction
Si la copie présente une régression, restaurez le composant précédent ou retirez la modification par le canal de déploiement prévu. Vérifiez le démarrage de WordPress puis créez une nouvelle connexion d’essai. Le retour du fichier agit sur les valeurs émises ensuite. Des sessions déjà raccourcies ou retirées peuvent encore demander une reconnexion. Préparez les utilisateurs à ce comportement au lieu de restaurer une base ancienne pour récupérer des sessions.
Sur un site en service, choisissez une fenêtre avec le responsable du contenu. Demandez l’enregistrement du travail avant toute fermeture de sessions existantes et vérifiez un brouillon de démonstration après retour. Si une application métier dépend d’une session longue, faites traiter ce besoin par une politique validée, avec un périmètre précis et une revue. Évitez d’allonger globalement toutes les sessions pour résoudre une difficulté limitée à une interface.
Si l’accès au tableau de bord est perdu à cause d’une erreur de code, utilisez le canal d’hébergement de secours pour remettre la version valide. Conservez le message d’erreur expurgé et l’identifiant de déploiement. La correction doit viser la configuration, avec une nouvelle vérification des parcours qui avaient échoué.
Remettre les durées et les résultats réellement observés
La fiche finale doit indiquer la valeur choisie, les comptes ou environnements concernés, le traitement de la mémorisation et les parcours testés. Ajoutez les heures de création de sessions et les résultats des nouvelles requêtes après attente. Si une connexion unique intervient, indiquez le responsable et le résultat du test de fermeture de son propre accès. Une politique écrite doit pouvoir être reproduite sur un poste configuré de la même façon.
Le filtre présenté est une fonction du cœur WordPress. Sa mise en place ne nécessite pas d’extension commerciale lorsque l’équipe maintient déjà un composant de configuration. Une offre de sécurité ou de connexion unique peut proposer une autre gestion des sessions, avec des limites à vérifier dans son contrat. Ne confondez pas une durée depuis connexion avec une fonction commerciale d’inactivité sans en avoir contrôlé le comportement.
Conservez les références de la version précédente et du moyen de retour. Programmez une nouvelle revue lors d’un changement de navigateur, de méthode de connexion ou de politique des postes partagés, car ces éléments participent au résultat de bout en bout.
L’Atelier WordPress.
