Problèmes d'accès au site
Certains de mes utilisateurs ont des difficultés à accéder à mon site Web. Soit le site ne se charge pas du tout (erreur telle que "le serveur n'a envoyé aucune donnée"), soit son navigateur ne peut simplement pas se connecter à mon site (erreur telle que "vérifier la connexion réseau"). Pendant ce temps, leur accès à tout autre site est correct!
Je me gratte la tête pour essayer de résoudre ce problème, mais j’ai épuisé toutes les pistes possibles pour comprendre le problème et le résoudre.
L'une des astuces que nous avons trouvées était utile pour certains (pas tous): effacer l'historique du navigateur, le cache et les cookies. Le site est apparu et a bien fonctionné pour eux à nouveau - pour un temps inconnu (mais court).
Il n'est pas possible de suivre un navigateur, un système d'exploitation ou un périphérique unique. Cela arrive aux utilisateurs de pratiquement toutes les combinaisons appareil/navigateur. Et bien que cela arrive pour certains utilisateurs sur un périphérique, un autre fonctionnera toujours correctement pour eux. Argh!
Un utilisateur particulièrement utile me tient au courant de ses problèmes de connexion à notre site et, dernièrement, il doit supprimer les cookies, etc. en moins d'une heure pour retrouver l'accès à mon site!
Un autre utilisateur très utile a mentionné un autre problème, pour lequel il ne peut pas accéder à notre site en saisissant manuellement l’URL dans la barre d’adresse, mais il peut très bien y accéder en cliquant sur un lien menant à un autre site Web. Cela dit, il ne peut pas charger le site à partir de notre lien dans les résultats de recherche Google!
Je suis épaté. Des preneurs ici? J'aimerais entendre toutes les suggestions. Nous avons peut-être déjà essayé sans succès, mais peut-être que quelqu'un aura une idée que nous n'avons pas encore essayée?
Détails du site: Magento 1.9.2.4 (entièrement mis à jour à ce jour), utilisant le thème Intenso Hébergé sur un serveur dédié: Dell Poweredge R220, 32 Go de RAM, 2 x 256 Go de SSD Samsung Enterprise (raid 1), Quad Core - 8 x Intel Xeon E3 -1271 v3 CPU E3 @ 3.6Gh
Serveur exécutant CentOS 6.8 et Apache
URL: https://www.modelhelicopters.co.uk/
Cordialement, Rob
Lorsque vous commencez à voir ces problèmes intermittents et qu’ils affectent les clients de divers systèmes, plates-formes technologiques et réseaux, le problème est le plus souvent lié à la santé générale d’Internet. En notant la date de votre question en janvier et en y regardant de près, ce que j’ai pu constater, c’est qu’il y avait des problèmes intermittents de janvier à janvier, ce qui a amené cette question à être soulevée par plusieurs personnes. De manière plus générale, les questions de dépannage que vous devriez poser comprennent:.
- Cela n'affecte-t-il qu'un seul type de navigateur? Si cela concerne seulement un type de navigateur, testez votre site au niveau du développement et comparez-le avec celui-ci pour voir si des mises à jour récentes du navigateur ont été mises à jour, ou Une combinaison d’extensions affecte quelque chose sur votre site. Dans votre cas particulier, il serait inhabituel car cela devrait continuer d’affecter le site jusqu’à ce que l’extension ou le navigateur ait été modifié et devrait toucher la plupart des utilisateurs de cette combinaison de navigateur et d’extension.
- Cela affecte-t-il les clients d'un fournisseur de services Internet? Compte tenu de la méthode de peering, il peut arriver qu'une partie d'Internet soit bloquée pour les clients d'un fournisseur de services Internet s'ils commettent une erreur de configuration de routage sur leurs passerelles. Cela s'est déjà produit en Australie, où un fournisseur de services Internet a commis une petite erreur en configurant son routage sur une passerelle desservant un seul État, ce qui a amené ses clients de cet État à perdre l'accès à tous les sites européens tout en maintenant l'accès aux États-Unis et au Canada. Sites australiens sans problème.
- Cela affecte-t-il la totalité ou un pourcentage élevé de vos clients? Cela pourrait indiquer un problème avec votre serveur ou le réseau de vos fournisseurs d'hébergement. Ce que vous pouvez faire ici n’est pas énorme, si ce n’est soulever un ticket d’assistance auprès du fournisseur pour lui demander d’examiner le problème et de voir si un problème peut être identifié. Sur un serveur partagé, il est possible que d'autres clients aient déjà contacté le fournisseur d'hébergement, mais avec un serveur dédié, en fonction du réseau, l'erreur peut ou non affecter d'autres clients d'hébergement.
Dans votre situation particulière, j'aurais tendance à examiner davantage un problème de niveau réseau. D'après mes commentaires, des suggestions ont été faites pour la surveillance du service, mais je vais aller un peu plus loin. Vous notez que votre fournisseur d’hébergement effectue la surveillance, je vous encourage à faire votre propre surveillance, car la plupart des fournisseurs d’hébergement qui effectuent cette surveillance effectuent une surveillance centrée sur les systèmes qui surveille les alarmes mais qui n’enlève pas toujours tout. La meilleure pratique consiste à effectuer une surveillance centrée sur le client qui surveille les performances du site lui-même en tant que site Web et non pas uniquement en tant que point d'extrémité du réseau. Les moins chers vérifieront simplement si le serveur peut être ping, mais les meilleurs effectueront une vérification HTTP sur le site et vérifieront que le site lui-même revient, le temps qu'il faut pour servir, etc., et si les seuils de temps sont dépassés, ou le site Web est hors ligne, ou quelque chose d'autre que le site est desservi, puis une alarme est déclenchée et un courrier électronique est envoyé. Vous devriez également utiliser les services qui vérifient de nombreux réseaux à travers le monde, car cela vous donnera une meilleure idée de la façon dont les choses se présentent, des erreurs pouvant uniquement affecter les utilisateurs, que ce soit dans un pays ou même sur une plage limitée de niveaux 2. réseaux régionaux de déchirure 1, plutôt qu’Internet en général.
Correction potentielle de Magento
Sur la base de vos commentaires sur cette réponse, j'ai ajouté cette modification en fonction d'informations supplémentaires que j'ai pu trouver.
Il semble y avoir une erreur connue dans le noyau de Magento où la logique nécessaire pour renouveler le cookie frontend_cid est manquante. Une autre personne a rencontré le cookie manquant mais ne semble pas entrer dans les détails sur l’erreur provoquée, à part dire que les sessions étaient en train de mourir.
Magento a fourni un correctif qu’ils n’ont apparemment pas réussi à publier mais que la personne a publié afin que vous puissiez essayer de le tester et voir comment cela se passe. S'il est causé par la même erreur racine, le problème sera dans app/code/core/Mage/Core/Model/Session/Abstract/Varien.php. Ce que le patch fait est de remplacer
if (Mage::app()->getFrontController()->getRequest()->isSecure() && empty($cookieParams['secure'])) {
// secure cookie check to prevent MITM attack
$secureCookieName = $sessionName . '_cid';
if (isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])
&& $_SESSION[self::SECURE_COOKIE_CHECK_KEY] !== md5($cookie->get($secureCookieName))
) {
session_regenerate_id(false);
$sessionHosts = $this->getSessionHosts();
$currentCookieDomain = $cookie->getDomain();
foreach (array_keys($sessionHosts) as $Host) {
// Delete cookies with the same name for parent domains
if (strpos($currentCookieDomain, $Host) > 0) {
$cookie->delete($this->getSessionName(), null, $Host);
}
}
$_SESSION = array();
}
if (!isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
$checkId = Mage::helper('core')->getRandomString(16);
$cookie->set($secureCookieName, $checkId, null, null, null, true);
$_SESSION[self::SECURE_COOKIE_CHECK_KEY] = md5($checkId);
}
}
avec
if (Mage::app()->getFrontController()->getRequest()->isSecure() && empty($cookieParams['secure'])) {
// secure cookie check to prevent MITM attack
$secureCookieName = $sessionName . '_cid';
if (isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
if ($_SESSION[self::SECURE_COOKIE_CHECK_KEY] !== md5($cookie->get($secureCookieName))) {
session_regenerate_id(false);
$sessionHosts = $this->getSessionHosts();
$currentCookieDomain = $cookie->getDomain();
foreach (array_keys($sessionHosts) as $Host) {
// Delete cookies with the same name for parent domains
if (strpos($currentCookieDomain, $Host) > 0) {
$cookie->delete($this->getSessionName(), null, $Host);
}
}
$_SESSION = array();
} else {
/**
* Renew secure cookie expiration time if secure id did not change
*/
$cookie->renew($secureCookieName, null, null, null, true, null);
}
}
if (!isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
$checkId = Mage::helper('core')->getRandomString(16);
$cookie->set($secureCookieName, $checkId, null, null, null, true);
$_SESSION[self::SECURE_COOKIE_CHECK_KEY] = md5($checkId);
}
}
Désormais, si votre installation Magento manque également de la logique pour renouveler le cookie frontend_cid comme vous l'indiquez dans vos commentaires, cela pourrait résoudre le problème pour vous. Il a été fourni sous forme de correctif SUPEE-7136 mais je n’ai pas pu le trouver publié à ce jour par aucun canal officiel. Cependant, l’autre personne qui a rencontré ce problème ne l’a rencontré que le mois d’octobre de l’année dernière. possibilité que vous ayez un problème similaire causé par la même cause fondamentale.