Le problème que j'ai, c'est que je ne peux pas vous connecter à mon wiki nouvellement créé que j'ai fait à l'aide de MediaWiki. J'ai cherché le Web pour une réponse et ceux que j'ai trouvés n'a pas aidé à ce problème spécifique (comme celui-ci: Problème avec les cookies MediaWiki ) J'ai essayé avec plusieurs navigateurs et modifié le paramètre pour vous assurer que les cookies sont activés, mais je continue à obtenir la même erreur:
" wiki utilise des cookies pour vous connecter à des utilisateurs. Vous avez des cookies désactivés. S'il vous plaît activez-les et réessayez. " "
Je ne sais pas si c'est un problème avec ma version actuelle de PHP, qui est actuellement de 5,3, ou un cadre dans mon wiki.
12 Réponses :
J'ai trouvé une solution, je vais le mettre en étapes:
LOCALALSETTS.PHP
- aller au bas de la page et entrez dans le code suivant:
session_save_path ("TMP");
- Créer un répertoire appelé
TMP dans le dossier où vous avez MEDIWIKI installé.
Heureux que tu as réparé. Je ne connais pas ce logiciel, mais c'est l'emplacement où il est installé la racine Web du site? Si tel est le cas, essayez d'accéder à http: // YourSite / TMP et http: // YourSite / TMP /
+1 Pour ajouter votre propre réponse, cela est encouragé ici. N'oubliez pas de cocher cela, pour remonter la question des listes «sans réponse».
@halfer: J'étais sur le point de mentionner la même chose. (PS. Pour MediaWiki, une URL plus probable serait quelque chose comme http: // votrersite / w / tmp / .)
Cela fait sens @halfer, je m'assurerai qu'il n'y a pas de problèmes de sécurité avec le répertoire TMP.
Le problème est pourquoi j'ai besoin de la fonction Session_Save_Path, comment trouvez-vous cette méthode pour résoudre ce problème?
Il fonctionne pour moi en définissant le répertoire en dehors de public_html ( session_save_path ('../ mediaki-cookies-tmp'); )
Si vous utilisez Nginx + PHP-FPM, les réponses précédentes ne résoudront probablement pas votre problème.
De mon expérience, ce problème est causé lorsque PHP-FPM n'a pas d'accès en écriture au cookie_Path. Vous pouvez trouver ce chemin en exécutant: Voir ce que votre cookie_path est, puis STAT le dossier et assurez-vous que votre utilisateur PHP-FPM a un accès en écriture. Pour résoudre ce problème à l'aide de Nginx et de PHP-FPM, je devais modifier mon cookie_path de sa valeur par défaut de / (sérieusement, pourquoi cela serait-il une valeur par défaut?) à /tmp. After redémarrage nginx et php-fpm, cela fonctionne parfaitement.
Même chose peut arriver lorsque MemCached est utilisé pour stocker des fichiers de session. Dans ce cas, Wiki ne parviendra pas à écrire des cookies ni in / ni in / tmp. Si vous voyez en erreur.Log quelque chose comme "Fichier non trouvé (11211: 9001: 9001: 9001: 9001: 9001: 9001 / Qweqweqweqweqe)" Cela signifie que vous avez installé et configuré Memchached et vous devez ajouter les lignes suivantes dans LOCALALSETTS.PHP:
$wgMainCacheType = CACHE_MEMCACHED; $wgParserCacheType = CACHE_MEMCACHED; # optional $wgMessageCacheType = CACHE_MEMCACHED; # optional $wgMemCachedServers = array( "127.0.0.1:11211" ); $wgSessionsInMemcached = true; # optional
J'ai aussi eu ce problème ...
Tous mes navigateurs se plaignaient des cookies étant désactivés ...
I Thouhgt Une politique de groupe avait été mise en œuvre pour désactiver les cookies. Après avoir conféré avec mon équipe de support de serveur que rien de tel n'a été mis en œuvre, j'ai décidé de télécommander au serveur.
Le serveur se plaint de l'espace disque bas. J'ai nettoyé le disque en supprimant quelques vieux fichiers non liés.
J'ai essayé de vous connecter à nouveau de mon navigateur et tout allait bien.
C'est aussi la même cause première cause que j'avais ... Je devais simplement supprimer le nouveau fichier [énorme] que j'ai mis sur le serveur car les symptômes sont apparus
être root: puis modifier le fichier et défini ces Variables TO / TMP: P> php.ini code>: p> chmod -R 1777 /tmp
session.cookie_path ne pointe pas un répertoire mais gère le chemin de domaine voir php.net/manual/fr/function.session-set-cookie-params.php
a juste couru dans ce numéro sur un serveur R2 Win2008 R2 exécutant IIS, Lors de la création d'un utilisateur a donné ce message (rouge) msg:
Erreur de création de compte Le compte d'utilisateur n'a pas été créé, comme nous le pouvions ne pas confirmer sa source. Assurez-vous que vous avez activé des cookies, rechargez ceci Page et essayez à nouveau.
En outre, si un utilisateur a essayé de se connecter au wiki, ils obtiendraient cette (rouge) msg:
Erreur de connexion (Wikiname) utilise des cookies pour vous connecter aux utilisateurs. Vous avez des cookies désactivée. Veuillez leur permettre et réessayer.
Échec des tentatives:
- J'ai essayé la solution de Jesseg17, mais je n'ai pas pu enregistrer des modifications à la
localsettings.php fichier (malgré l'arrêt du serveur).- J'ai vérifié les autorisations sur l'emplacement Temp, mais cela n'a pas aidé.
- J'ai changé essayé de changer l'emplacement Temp via le gestionnaire PHP de l'IIS, mais cela n'a rien changé.
Qu'est-ce qui a finalement travaillé était d'utiliser le responsable PHP d'IIS pour changer le Les paramètres PHP de Mediawiki;
session.use_cookies de 0 à 1Cela a résolu le problème sans redémarrer.
Une réponse qui n'a pas été mentionnée ici - assurez-vous que votre système de fichiers n'est pas hors de l'espace.
La solution la plus facile, également Recommandé par Aaron Schulz , est généralement de définir dans votre Voir aussi Cache documentation. localsettings.php . Dans PHP récent, vous aurez OPCACHE activé par défaut; Si aucun accélérateur n'est disponible, à la pire de cette configuration utilisera la base de données.
Après une journée complète, j'essaie beaucoup de configurations ont finalement trouvé votre réponse. Le seul qui fonctionne réellement. Installation fraîche de Wikimedia 1.3.0 + PHP-FPM 7.0 + NGinx 1.12.
J'ajoute une nouvelle réponse parce que ma configuration était légèrement différente et que les étapes que j'ai prises étaient similaires mais pas identiques à toutes les autres.
J'ai installé MediaWiki sur Centos avec Nginx. Après avoir exécuté avec succès pendant quelques mois, j'ai commencé à obtenir la même erreur de cookie de nulle part. P>
P>
Le problème I Si l'utilisateur PHP-FPM avait eu accès au dossier session.save_path code>. Je ne sais pas pourquoi c'est arrivé, mais voici maintenant je l'ai réparé. P>
Une autre chose à vérifier est si votre répertoire TMP de session est plein. Les symptômes sont des messages «Échec de l'écriture» dans votre journal d'erreur HTTP Server. Duh!
Je devais transformer le paramètre wgcookiesecure dans LOCALALSETTINGS.PHP:
n'a trouvé que cela après avoir vérifié qu'un autre wiki sur le même ordinateur a été bien fonctionné avec des paramètres similaires. Donc, pour vous déboguer, vous voudrez peut-être installer un MediaWiki frais dans un répertoire voisin et vérifier si cela vous donne des problèmes. Alors vous pouvez aller à travers toutes les suggestions ici ainsi que celle à
https://www.mediawiki.org/wiki/topic:rg3w5u0e70fs8l4e # $ wgcookiesecure = true;
Utilisez FIDDLER et voir si les cookies sont envoyés du serveur au navigateur. Sinon, il y a quelque chose qui ne va pas avec votre serveur. Dans les deux cas, mettez à jour votre question avec des conclusions.
Comment saurai-je que si cela se passe?
Regardez la réponse et voyez si l'en-tête de cookies est défini.
Quel navigateur utilisez-vous? Avez-vous essayé un autre navigateur? Exécutez-vous MW sur la machine locale ou sur un hôte distant? Y a-t-il quelque chose entre vous et le serveur Web qui pourrait être des biscuits?
Comme je l'ai dit, j'ai utilisé plusieurs navigateurs. J'ai essayé avec Chrome, Safari, Firefox et même Opéra, et m'assurer que les cookies étaient activés, mais cela ne fonctionnait toujours pas.
Oh, et j'ai aussi essayé c'est-à-dire. Et il est exécuté sur un serveur Webserver @halfer.
Righto, +1 à ceci. Voir le point de l'@ Alexei sur la vérification des cookies dans les en-têtes (vous pouvez le faire avec la barre d'outils du développeur Web dans Firefox et probablement de nombreuses autres manières également).
Merci beaucoup pour votre aide, j'ai trouvé un correctif à cela. Je pose une réponse ici maintenant.