J'ai installé Magento 1.9 . Cela fonctionnait bien pendant une semaine. Soudainement hier, lorsque j'ai essayé de me connecter au panneau d'administration Magento et que j'ai tapé username
et password
cliqué sur le bouton Connexion, rien ne s'est passé. La page se rafraîchit et c'est tout. Aucune erreur ni aucun autre message.
Si j'ai entré un nom d'utilisateur ou un mot de passe incorrect, l'erreur est indiquée.
Après avoir cherché sur ce sujet dans Google, on m'a recommandé de commenter les lignes suivantes:
app \ code \ core \ Mage \ Core \ Modèle \ Session \ Abstract \ Varien.php
/* to solve login issue */
/*if (!$cookieParams['httponly']) {
unset($cookieParams['httponly']);
if (!$cookieParams['secure']) {
unset($cookieParams['secure']);
if (!$cookieParams['domain']) {
unset($cookieParams['domain']);
}
}
}
if (isset($cookieParams['domain'])) {
$cookieParams['domain'] = $cookie->getDomain();*/ //I have commented these lines
Et pour certaines versions plus anciennes ci-dessous a été recommenté dans le même fichier.
$cookieParams = array(
'lifetime' => $cookie->getLifetime(),
'path' => $cookie->getPath(),
//'domain' => $cookie->getConfigDomain()
//'secure' => $cookie->isSecure(),
//'httponly' => $cookie->getHttponly()
);
}*/
Même après cela, je ne pouvais plus me connecter à admin. C'est comme ça. Quelqu'un a affronté ce problème? Existe-t-il une autre solution à ce problème?
(J'ai essayé de vider le cache et la session via ftp).
la source
app/code/local/Mage/Core..blahblah
pour les éditer afin que Magento remplace le fichier de base. Également utiliser git pour le contrôle de version, c'est une aubaine.Réponses:
Arrêtez de modifier le code principal de cette manière - cela peut résoudre temporairement un problème, mais peut créer des problèmes futurs qu'il sera presque impossible de dépister.
Plusieurs problèmes différents sont à l' origine du comportement de connexion sans erreur de l'administrateur que vous constatez, mais ils sont tous liés au fait que Magento n'est pas en mesure de définir ou de lire le cookie de session. Magento utilise des sessions pour transmettre des messages d'erreur entre les pages. C'est pourquoi vous ne voyez pas de message d'erreur. Magento utilise également des sessions pour stocker la valeur "est connecté", aussi le fait de ne pas définir de session entraîne également le comportement d'erreur fondamentale.
Les causes possibles incluent
Non concordance entre l'heure de l'ordinateur local et l'heure du serveur, ce qui entraîne l'invalidation instantanée du cookie. Assurez-vous que l'heure de votre serveur est correcte.
Autorisations incorrectes sur
var/session
, empêchant l'enregistrement des fichiers de sessionConfiguration incorrecte de la base de données / redis / autre stockage de session, empêchant l'enregistrement des valeurs de session
Un module instancie les sessions trop tôt , ce qui empêche de définir les noms de session corrects.
Vous êtes un développeur utilisant plusieurs URL et possédez plusieurs domaines de cookie.
Un autre développeur a en quelque sorte modifié
app\code\core\Mage\Core\Model\Session\Abstract\Varien.php
, créant un bogue difficile à détecterLe domaine de cookie en
System -> Configuration -> Web -> Session Cookie Management
ne correspond pas au domaine de site actuel.Vous utilisez le domaine en
localhost
tant que votre serveur et utilisez une version de webkit présentant des problèmes / problèmes de configuration des cookieslocalhost
dans certaines situations.La solution à court terme consiste simplement à supprimer votre cookie pour le domaine. C'est souvent suffisant pour résoudre le problème. Si le problème persiste, déterminez laquelle des raisons ci-dessus est la raison de votre erreur et prenez des mesures pour y remédier (autorisations de réparation, etc.).
la source
Je rencontre les mêmes symptômes sur certaines installations de Magento (pas seulement 1.9). Dans mon cas, cela ne se produit que dans Chrome. Je résous ce problème en me connectant à Firefox / Safari / Opera et en modifiant l'option "Utiliser HTTP uniquement" en "Non" dans "Gestion des cookies de session" des paramètres "Web".
la source
Use HTTP only
àNo
sans accès au panneau d'administration. Vous pouvez lancer directement cette requête SQL: UPDATE__DATABASE_NAME__
.core_config_data
SETvalue
= '0' OÙcore_config_data
.path
= 'web / cookie / cookie_httponly';J'ai eu ce problème également. Les sessions avérées ne peuvent pas être écrites
var/session
, même si le répertoire lui-même est défini sur0777
. Magento a créé des fichiers de session, mais ils sont tous restés à zéro octet.Changer le stockage de session de
files
pourdb
résoudre le problème pour moi.la source
Commentez comme ça:
/*error_reporting(E_ALL | E_STRICT);*/
Et utilisez plutôt le code suivant:
error_reporting(E_ALL);
$_SERVER['MAGE_IS_DEVELOPER_MODE'] = true;
Décommentez-le en supprimant le signe #, il a donc l'aspect suivant:
ini_set('display_errors', 1);
Enregistrez ce fichier et téléchargez-le sur le serveur. Rechargez votre page Web pour voir les erreurs.
la source
Une autre raison possible: le disque dur / volume / quota est saturé et les données de session ne peuvent donc pas être écrites sur le disque. Cela peut sembler peu probable, mais cela m'est arrivé une deuxième fois et j'ai mis du temps à comprendre.
Je n'ai pas assez de réputation pour commenter, mais @ Alan Storm, vous voudrez peut-être inclure cela dans votre excellente liste.
la source
J'ai récemment eu le même problème et simple astuce a fonctionné pour moi. Il s’agit également des personnes qui ne peuvent pas accéder au tableau de bord sur Google Chrome . Si vous pouvez travailler sur Mozilla Firefox, veuillez le faire car je suppose que ce problème n’est pas persistant sur Mozilla Firefox.
La solution pour le chrome est donc:
Aller sur Système-> Configuration-> Web . Développez l' onglet Unsecure and Secure . Modifiez l'URL de base en
http://127.0.0.1/[Your folder name]
si vous utilisez localhost ou modifiez-la en l'URL de votre site par laquelle vous accédez à l'interface. J'ai dû me connecter deux fois pour accéder au tableau de bord, car lorsque j'ai entré les détails pour la première fois, il est simplement actualisé et revient à la même page que celle que vous avez décrite en tant que boucle.la source
Ouvrez votre phpMyAdmin depuis votre hôte essayez une fois cette commande SQL.
Exécutez ce SQL:
Maintenant, l’administrateur peut se connecter.
Veuillez suivre ceci:
La page Admin montre 404 pages non trouvées
la source
J'ai eu le même problème et je l'ai résolu en supprimant tous les fichiers de / var / session. Je pense que c'est parce qu'il y a trop de sessions dans Magento!
la source
La liste des tempêtes d’alarme est correcte et détaillée. Voici quelques cas supplémentaires.
var/session
machine hôte(problèmes de montage)
n98-magerun.phar sys:check
(problèmes rencontrés, y compris domaine du cookie)Changez de session en base de données en modifiant le fichier local.xml. Il éliminera la plupart des problèmes de permission en utilisant insidie
<global>
Faites également varier les extensions tierces (extensions de pare-feu / de sécurité), par exemple https://github.com/paimpozhil/MageFirewall/blob/master/app/code/community/MageFirewall/Firewall/Model/Observer.php#L53 vous met sur la liste noire si vous essayez trop de fois.
Peut se produire si votre session ne fonctionnait pas à l'origine pour des problèmes d'autorisation, mais continue ensuite à échouer même après avoir résolu le problème d'origine
Dans votre cas particulier, gardez un œil sur l'
admin_session_user_login_success
événement car la plupart des modules de sécurité / pare-feu utilisent cet événement. Surveillez spécialement si la variable$_SESSION['admin']
est réinitialisée par les observateursla source
Il est également important d'avoir une clé de formulaire présente, sinon votre formulaire ne sera pas traité.
la source
Une solution simple à ce problème consiste à utiliser http://127.0.0.1 comme nom d’hôte au lieu de localhost.
Le problème étant que vous ne pouvez pas vous connecter à votre administrateur, vous devez modifier les URL de base sécurisées et non sécurisées dans la base de données tabel: core_config_data.
Cela permettra également à votre baseurl de valider avec le système de n98-magerun: check
la source
Si vous développez
localhost
et avez défini ou modifié votre nom de domaine surlocalhost
, mettez à jour lescore_config_data
noms de domaine de votre table de base de données sur127.0.0.1
. Par exempleUPDATE core_config_data SET value="http://127.0.0.1/magento/" WHERE path="web/unsecure/base_url";
la source
En outre, vous pouvez mettre à jour le mot de passe dans la base de données si tout ce qui précède ne fonctionnait pas et si vous avez besoin d'un accès urgent:
remplacez les mots d’utilisateur et de mot de passe en fonction de vos besoins.
la source
Tout d’abord, essayez de vider le cache et, si cela ne fonctionne pas, essayez de créer chmod 700 dans votre dossier var.
la source
Vous pouvez changer votre navigateur peut être ce travail pour moi. Lorsque cette erreur survient, j’ai changé le navigateur Chrome pour Firefox et le fonctionne.
la source
La même chose s’est produite avec moi il ya quelque temps et mon problème vient de la session. Je n'avais pas assez d' espace disque pour créer les sessions et la mémoire cache
var/
. J'ai enlevé des trucs et tout a fonctionné après. Cela aidera peut-être quelqu'un.À votre santé
la source
Essayez de vider votre cache en vidant les dossiers "var / cache" et "var / session", cela a résolu le problème.
J'ai également dû redémarrer le serveur Web après l'avoir fait une fois.
la source