Manual:How to debug/Login problems/fr

Les problèmes de connexion ou de session (comme le fait de ne pas pouvoir se connecter, de se déconnecter immédiatement, de se déconnecter de manière aléatoire, de ne pas pouvoir modifier en raison d'erreurs de "perte de données de session") peuvent être causés par une grande variété de raisons, ce qui rend le débogage difficile.

Lorsque vous recherchez ou signalez des erreurs, voici quelques conseils.



Pour les utilisateurs

 * Si le problème est de ne pas pouvoir de vous connecter à cause d'erreurs du type Il semble y avoir un problème avec votre session de connexion..., l'effacement de tous les cookies pour ce site aide généralement.
 * Lorsque vous rédigez un rapport de bogue, indiquez toujours le navigateur (et sa version) que vous utilisez, si vous l'utilisez en mode incognito et si vous utilisez des paramètres de confidentialité ou de sécurité non par défaut (comme bloquer les cookies tiers).
 * Lorsque c'est possible, joignez la date et l'heure précises à laquelle vous avez rencontré le problème, afin qu'il puisse être relié avec les journaux du système.
 * Vous n'avez pas besoin de faire une enquête approfondie mais juste déposer un rapport de bogue, et si vous le voulez, voici quelques types d'informations qui sont généralement utiles :
 * Est-ce qu'il persiste après avoir effacé les cookies pour le domaine du wiki ? Lors de la connexion utilisez-vous le mode incognito du navigateur ? Lorsque vous vous connectez avec un autre type de navigateur ?
 * Si vous utilisez des bloqueurs de publicité ou des modules complémentaires de confidentialité du navigateur, bloquent-ils quoi que ce soit ? Est-ce que ça marche si vous les désactivez ?
 * Cela affecte-t-il plusieurs comptes utilisateurs, ou bien un seul ?
 * Le drapeau "Souviens-toi de moi" fait-il une différence ? (Effacer les cookies avant les tentatives).
 * Si les problèmes se produisent sur un wiki Wikimedia, essayez de vous connecter sur un autre wiki, de préférence celui qui ne partage pas un nom de domaine de second niveau (donc si le problème se produit sur xy.wikipedia.org, essayez par exemple avec xy.wiktionary.org).
 * Si les informations ci-dessus ne sont pas suffisantes pour analyser le problème (ce qui est souvent le cas), vous allez avoir besoin de demander à récupérer les données détaillées de débogage. Pour cela, vous devez capturer les requêtes et les réponses HTTP pertinentes (c.-à-d. visiter la page de connexion + soumettre le formulaire de connexion + la redirection résultante; et si le wiki utilise la connexion unique, toutes les requêtes à  et   aussi). Cela peut être fait en utilisant l'onglet Réseau dans les Outils de développement de votre navigateur web (plus d'informations: Firefox, Internet Explorer, Chrome et Chromium, Safari). Le vidage dans un fichier HAR est un moyen facile d'enregistrer toutes les données requises.
 * Notez bien que cela inclut des données sensibles à la sécurité (comme votre identifiant de session); lorsque vous partagez les informations dans le cadre d'un rapport de bogue, vous devez utiliser un collage privé. Vous êtes encouragé à supprimer votre mot de passe du rapport (dans le cas d'un fichier HAR, vous pouvez simplement l'ouvrir sous forme de fichier texte, rechercher le mot de passe et le remplacer par autre chose) et à vous déconnecter et à vous connecter à nouveau par la suite.



Pour les développeurs
Lorsque vous déboguez les problèmes de connexion à MediaWiki par défaut, recherchez les éléments suivants :
 * On Special:Userlogin, does the website set the  cookie? Is the cookie sent back correctly when the login form is submitted? Does the cookie value persist during multi-step login (e.g. 2FA)? Does the session exist in the backend (you can check with , using shell.php).
 * If you are debugging an API-based login, the cookie should instead be set by the response to  and returned in the   request. Clients failing to do this is the most common source of login errors. (Note that the best practice for bots and similar clients is to use owner-only consumers and not use login at all.)
 * After a successful login, are the,  ,  ,   cookies set (the last one only when the "keep logged in" checkbox was used)? Do the   /   /   fields match in the data stored in the backend? Does the token match the value of   in the database?
 * If you want to check things with a debugger like XDebug, for session/cookie problems the interesting parts tend to be the  method of the session provider (usually  ), and  . For problems with processig the submitted login request, it's   and the   and   methods of the primary authentication provider (by default  ). Note that these are pretty complex codebases and will be hard to understand if you aren't familiar with SessionManager and AuthManager.
 * See also the advice about logging in the next session.

When debugging CentralAuth (e.g. Wikimedia sites), the things to look for: There's an overview of CentralAuth authentication features available.
 * On top of the normal cookies, there should also be,   and (with the "keep logged in" option)   (typically set on the parent domain). These should be enough to recreate the other cookies when those are missing. The session cookie corresponds to the central session; its data can be checked with   (using shell.php). The token corresponds to   in CentralAuth's shared database.
 * After a successful login, there should be a chain of redirects to  →   → back to the initial page (or   target). The /start step sets up a stub central session, and sets cookies for the central domain; the /complete step finalizes the central session, and sets cookies for the local domain. (See phpdoc in   for a more detailed description.) Are the cookies emitted as expected? Does the browser actually persist them? Is the data stored in the central session backend correct? If this step doesn't work, edge login / autologin won't work either.
 * The "keep logged in" flag (ie. the  cookie) is set in a separate step, by a request to Special:CentralAutoLogin/refreshCookies that's triggered from an  tag when the rest of the autologin is finished. Are the cookies emitted? Does the browser actually persist them? When this step doesn't work, edge login / autologin will stop working when the central session expires in a day or so.
 * Right after central login, edge login is triggered: For every wiki in, there is a redirect chain to various Special:CentralAutologin subpages (/start → /checkLoggedIn → /createSession → /validateSession → /setCookies) via an image embedded in the page. The setCookies step should create a local session and set the session cookies. Are the cookies emitted? Does the browser actually persist them?
 * When visiting a wiki where you do not have an active session (and no shared cookies on the parent domain to create one), central autologin is triggered. This is basically the same as edge login, just in a script tag instead of an image tag, and the same things should be verified.
 * When central autologin fails, further attempts are prevented by setting the  localStorage flag; you might need to clear that when testing.
 * When visiting the login page while not having an active session, top-level autologin is triggered. This is basically the same as normal autologin, just with the whole page being redirected, instead of an embedded image doing the redirects, and the same things should be verified.



Pour les administrateurs de site

 * Vérifiez quel serveur de session est utilisé et assurez-vous qu'il fonctionne (les données sont en fait conservées entre les requêtes). La configuration la plus sûre est . Si vous n'êtes pas sûr de la façon dont il est configuré, ajoutez ce paramètre à la fin de votre LocalSettings.php.
 * Assurez-vous que n'est pas défini à   ou à , autrement les sessions de PHP écraseront celles de MediaWiki.
 * Assurez-vous que est défini à une chaîne vide. S'il est mal configuré, il marque les sessions comme étant invalides.
 * S'il est défini, assurez-vous que et  sont corrects.
 * Si est défini à , votre serveur web doit utiliser HTTPS..
 * Assurez-vous que le nom des hôtes correspond dans MediaWiki et Apache . Par exemple, pour le domaine   et le serveur web situé à   :
 * Et :
 * Si vous utilisez une ancienne version de MediaWiki (avant la 1.27), vérifiez la valeur de ; s'il vaut , testez que votre gestion de session PHP fonctionne (par exemple, que   est accessible en écriture).
 * Si vous faites un rapport de bogue :
 * Rapportez quelle version de MediaWiki vous utilisez et quels fournisseurs de session vous utilisez (valeur de ).
 * Vérifiez vos journaux pour les enregistrements pertinents, en particulier les canaux,  ,  ,   (en plus des canaux habituels  ,  ,  ). En plus,   si vous recherchez les problèmes de CAPTCHA, et   si vous utilisez cette extension.
 * Pour certains types de cache vous pouvez obtenir plus d'informations en initialisant le mode de débogage :
 * Veuillez ne pas réutiliser les anciens rapports de bogue à moins que vous ne soyez sûr qu'il s'agit de la même cause. Il y a beaucoup de rapports sur les problèmes passés, et les symptômes de l'événement semblent similaires aux vôtres (il existe de multiples façons pour que la connexion échoue) la cause est susceptible d'être différente.
 * Pour certains types de cache vous pouvez obtenir plus d'informations en initialisant le mode de débogage :
 * Veuillez ne pas réutiliser les anciens rapports de bogue à moins que vous ne soyez sûr qu'il s'agit de la même cause. Il y a beaucoup de rapports sur les problèmes passés, et les symptômes de l'événement semblent similaires aux vôtres (il existe de multiples façons pour que la connexion échoue) la cause est susceptible d'être différente.
 * Veuillez ne pas réutiliser les anciens rapports de bogue à moins que vous ne soyez sûr qu'il s'agit de la même cause. Il y a beaucoup de rapports sur les problèmes passés, et les symptômes de l'événement semblent similaires aux vôtres (il existe de multiples façons pour que la connexion échoue) la cause est susceptible d'être différente.