View source for Manual:How to debug/Login problems/fr

<languages/>
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.

<span id="For_users"></span>
== 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 retrouvé dans 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 à <code>Special:CentralLogin</code> et <code>Special:CentralAutoLogin</code> aussi). Cela peut être fait en utilisant l'onglet ''Réseau'' dans les ''Outils de développement'' de votre navigateur web (plus d'informations: [https://developer.mozilla.org/docs/Tools/Web_Console Firefox], [http://msdn.microsoft.com/en-us/library/ie/dn255006 Internet Explorer], [https://developer.chrome.com/devtools Chrome et Chromium], [https://developer.apple.com/safari/tools/ Safari]). Le [https://www.inflectra.com/support/knowledgebase/kb254.aspx 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 [https://phabricator.wikimedia.org/paste/edit/form/36/ utiliser un collage privé] (accès réservé aux développeurs). 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.

<span id="For_developers"></span>
== Pour les développeurs ==
Lorsque vous déboguez les problèmes de connexion à MediaWiki par défaut, recherchez les éléments suivants :
* Sur Special:Userlogin, est-ce que le site web a défini le cookie <code>&lt;wikiID>Session</code> ? Le cookie est-il renvoyé correctement lorsque le formulaire de connexion est soumis ? Est-ce que la valeur du cookie persiste durant la connexion en plusieurs étapes (comme 2FA) ? La session existe-t-elle sur le serveur (vouspouvez vérifier avec <syntaxhighlight lang="php" inline>ObjectCache::getInstance( $wgSessionCacheType ) )->get( "MWSession:$sessionCookieValue" )</syntaxhighlight>, en utilisant [[Special:MyLanguage/Manual:shell.php|shell.php]]).
** Si vous débogagez un login basé sur l'API, le cookie doit être configuré par la réponse à <code>meta=tokens</code> et renvoyé dans la requête <code>action=login</code>. Les clients qui ne le font pas sont la source la plus fréquente d'erreurs de connexion. (Notez que la meilleure pratique pour les robots et les clients similaires est d'utiliser les [[Special:MyLanguage/OAuth/Owner-only consumers|consommateurs propriétaires uniquement]] et de ne pas du tout utiliser le ''login'').
* Après un login réussi, est-ce que les cookies <code>&lt;wikiID>Session</code>, <code>&lt;wikiID>UserName</code>, <code>&lt;wikiID>UserId</code>, <code>&lt;wikiID>Token</code> sont-ils définis ? (ce dernier n'existe que lorsque si la case à cocher "Rester connecté" a été utilisée) Les champs <code>userId</code> / <code>userName</code> / <code>userToken</code> correspondent-ils aux données stockées sur le serveur ? Le jeton correspond-il à la valeur de <code>user.user_token</code> dans la base de données ?
* Si vous voulez vérifier des choses avec un débogueur comme [[Special:MyLanguage/Manual:How to debug#Debugger|XDebug]], pour les problèmes de session ou de cookies, les parties intéressantes sont généralement la méthode <code>provideSessionInfo()</code> du fournisseur de session (généralement <code>CookieSessionProvider</code>), et <code>SessionManager::loadSessionInfoFromStore</code>. Pour les problèmes de traitement de la demande de connexion envoyée, il s'agit de <code>AuthManager::continueAuthentication()</code> et des méthodes <code>getAuthenticationRequests()</code> et <code>beginPrimaryAuthentication()</code> du fournisseur d'authentification primaire (par défaut <code>LocalPasswordPrimaryAuthenticationProvider</code>). Notez que ces bases de code sont particulièrement complexes et seront difficiles à comprendre si vous n'êtes pas familier avec [[Special:MyLanguage/Manual:SessionManager and AuthManager|SessionsManager et AuthManager]].
* Voir aussi les conseils de connexion pour la prochaine session.

Lorsque vous déboguez CentralAuth (par exemple, les sites Wikimedia), les éléments à rechercher sont :
* En plus des cookies normaux, il doit y avoir également <code>centralauth_Session</code>, <code>centralauth_User</code> et (avec l'option "Rester connecté") <code>centralauth_Token</code> (typiquement initialisé sur le domaine parent). Ces cookies devraient suffire à recréer les autres cookies quand ceux-ci sont absents. Le cookie de session correspond à la session centrale; ses données peuvent être vérifiées avec <syntaxhighlight lang="php" inline>MediaWiki\MediaWikiServices::getInstance()->get( 'CentralAuth.CentralAuthSessionManager')->getCentralSessionById( $sessionCookieValue )</syntaxhighlight> (en utilisant [[Special:MyLanguage/Manual:shell.php|shell.php]]). Le jeton correspond à <code>globaluser.gu_auth_token</code> dans la base de données partagée de CentralAuth.
* Après un login réussi, il doit y avoir une chaîne de redirections <code>Special:CentralLogin/start</code> → <code>Special:CentralLogin/complete</code> → retour à la page initiale (ou à la cible de <code>returnTo</code>). L'étape ''/start'' configure une session centrale bouchon et définit les cookies pour le domaine central; l'étape ''/complete'' finalise la session centrale et définit les cookies pour le domaine local. (Voir phpdoc dans <code>SpecialCentralLogin</code> pour une description plus détaillée). Les cookies sont-ils émis comme prévu ? Le navigateur les conserve-t-il vraiment ? Les données stockées dans le serveur de la session centrale sont-elles correctes ? Si cette étape ne fonctionne pas, le login final ou l'autologin ne fonctionneront pas non plus.
** La marque "Rester connecté" (c'est-à-dire le cookie <code>centralauth_Token</code>) est défini dans une étape séparée, par une requête à Special:CentralAutoLogin/refreshCookies qui est déclenchée à partir d'une balise {{tag|img|open}} lorsque le reste de l'autologin est terminé. Les cookies sont-ils émis ? Le navigateur les conserve-t-il vraiment ? Lorsque cette étape ne fonctionne pas, le login final ou l'autologin cessent de fonctionner lorsque la session centrale expire (dans un jour ou plus).
* Juste après le login central, le login final est déclenché: pour chaque wiki de <code>$wgCentralAuthAutoLoginWikis</code>, il existe une chaîne de redirection vers les  différentes sous-pages de Special:CentralAutologin (/start → /checkLoggedIn → /createSession → /validateSession → /setCookies) via une image intégrée à la page. L'étape ''setCookies'' doit créer une session locale et définir les cookies de session. Les cookies sont-ils émis ? Le navigateur les conserve-t-il vraiment ?
* Lorsque vous visitez un wiki où vous n'avez pas de session active (et aucun cookie partagé sur le domaine parent pour en créer un), l'autologin central est déclenché. C'est essentiellement la même chose que le login final, juste dans une balise de script au lieu d'une balise d'image, et les mêmes choses doivent être vérifiées.
** Lorsque l'autologin central échoue, les autres tentatives sont bloquées si le drapeau localStorage <code>CentralAuthAnon</code> est défini; vous devrez peut-être supprimer cela lors du test.
* Lorsqu'une personne visite la page de connexion sans avoir ouvert de session, un autologin de haut niveau est déclenché. C'est fondamentalement la même chose que l'autologin normal, simplement en redirigeant la page complète, au lieu qu'une image intégrée ne fasse les redirections, et les mêmes éléments doivent être vérifiés.
Il existe une [[Extension:CentralAuth/authentication|vue d'ensemble]] des fonctionnalités d'authentification disponibles de CentralAuth.

<span id="For_site_administrators"></span>
== Pour les administrateurs de site ==
* Vérifiez quel serveur de session est utilisé ({{wg|SessionCacheType}}) 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 {{phpi|1=$wgSessionCacheType = CACHE_DB;}}. 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 {{php-ini|session.auto_start}} n'est pas défini à <code>1</code> ou à <code>true</code>, autrement les sessions de PHP écraseront celles de MediaWiki. ({{phabricator|T159567}})
* Assurez-vous que {{php-ini|session.referer_check}} 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 {{wg|CookieDomain}} et {{wg|CookiePath}} sont corrects.
* Si {{wg|CookieSecure}} est défini à <code>true</code>, votre serveur web doit utiliser HTTPS.
* Assurez-vous que le nom des hôtes correspond dans MediaWiki et Apache <code>httpd.conf</code>. Par exemple, pour le domaine <code>example.com</code> et le serveur web situé à <code>www.example.com</code> :
*:<syntaxhighlight lang="text">
# LocalSettings.php
$wgServer           = '//www.example.com';
$wgCanonicalServer  = 'https://www.example.com';
$wgSitename         = 'Example Wiki';

$wgSecureLogin      = true;
$wgCookieHttpOnly   = true;
$wgCookieSecure     = 'detect';
</syntaxhighlight>
*:Et :
*:<syntaxhighlight lang="text">
# httpd.conf
<VirtualHost *:80>
   ...
   ServerName example.com
   ServerAlias www.example.com *.example.com
   Redirect permanent / https://example.com/
   ...
</VirtualHost>

<VirtualHost *:443>
   ...
   SSLEngine on
   ServerName example.com
   ServerAlias www.example.com *.example.com
   ...
</VirtualHost>
</syntaxhighlight>
* Si vous faites un rapport de bogue :
** Rapportez quelle version de MediaWiki vous utilisez et quels fournisseurs de session vous utilisez (valeur de {{wg|SessionProviders}}).
** Vérifiez vos [[Manual:How_to_debug#Logging|journaux]] pour les enregistrements pertinents, en particulier les canaux <code>authentication</code>, <code>session</code>, <code>cookie</code>, <code>objectcache</code> (en plus des canaux habituels <code>exception</code>, <code>error</code>, <code>fatal</code>). En plus, <code>captcha</code> si vous recherchez les problèmes de CAPTCHA, et <code>CentralAuth</code> si vous utilisez cette extension.
** Pour certains types de cache vous pouvez obtenir plus d'informations en initialisant le mode de débogage :
**: <syntaxhighlight lang="php">
$wgHooks['SetupAfterCache'][] = function () {
    global $wgSessionCacheType;
    ObjectCache::getInstance( $wgSessionCacheType )->setDebug( true );
};
</syntaxhighlight>
** 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.

[[Category:Debug{{#translation:}}]]