recherche

Maison  >  Questions et réponses  >  le corps du texte

Session CodeIgniter 3 perdue lors de la régénération de l'ID de session à l'aide du pilote Memcached uniquement

<p>Je développe un projet de longue durée utilisant le framework CodeIgniter 3. Depuis plusieurs mois, nous rencontrons des problèmes de perte aléatoire de sessions. J'ai mis à jour les fichiers du framework vers la dernière version (3.1.13). Il semble que cela ait résolu le problème sur le serveur de développement, mais en production, il existe toujours. Mais j'ai remarqué que cela ne se produit désormais que lorsque la réponse envoie un nouveau cookie de session, ce qui se produit lorsque l'identifiant de session est régénéré. Lorsque je modifie <code>$config['sess_time_to_update']</code>, cela reflète correctement l'heure requise. </p> <p>La différence entre un serveur de développement et un serveur de production réside dans le pilote de session : c'est un fichier sur le serveur de développement, alors qu'en production, nous utilisons memcached. J'ai donc fait une expérience et changé le pilote en fichier et la session n'était plus perdue. J'ai également essayé de le configurer avec le pilote Redis et cela n'a pas posé de problèmes non plus. Il doit donc s'agir d'un problème avec le pilote Memcached. Mais je ne veux pas en échanger contre un autre. Il n'y a aucune erreur dans les journaux. J'ai également vérifié que le fichier php.ini et les variables memcached ont tous deux des valeurs par défaut. </p> <p>CodeIgniter v3.1.13, PHP 7.4.3, Amazon ElastiCache pour Memcached</p> <p>Voici la configuration : </p> <pre class="brush:php;toolbar:false;">$config['sess_driver'] = 'memcached'; $config['sess_cookie_name'] = 'ci_session'; $config['sess_expiration'] = 14400; $config['sess_save_path'] = 'host.com:11211'; $config['sess_match_ip'] = FAUX; $config['sess_time_to_update'] = 300; $config['sess_regenerate_destroy'] = FALSE;</pre> <p>Toute idée où chercher ou quoi vérifier serait grandement appréciée. </p>
P粉356361722P粉356361722459 Il y a quelques jours550

répondre à tous(2)je répondrai

  • P粉797855790

    P粉7978557902023-09-01 15:45:09

    Vérifiez cette réponse. Apparemment, ce problème peut survenir si vous définissez le délai d'expiration maximum de la session sur une valeur supérieure à la limite d'expiration de Memcached. Dans cet article, l'OP a résolu le problème en corrigeant les variables de configuration suivantes, vous pouvez essayer :

    define('SESSION_TIME_OUT', x);
    ini_set('session.gc_maxlifetime', SESSION_TIME_OUT);
    ini_set('session.cache_expire', SESSION_TIME_OUT);
    session_start();
    

    Une autre option consiste à supprimer la base de données memcached 并使用内存驻留 sqlite3 et à la remplacer par le magasin de sessions, je ne pense pas que les performances en production seront très différentes dans les deux cas.

    répondre
    0
  • P粉762730205

    P粉7627302052023-09-01 11:17:20

    Si vous utilisez un cluster AWS ElastiCache Memcached, vérifiez le point de terminaison que vous utilisez dans votre configuration $config['sess_save_path']。一种选择是使用配置端点(其中包含 .cfg.),另一种选项是单个节点端点(包含 .0001..0002. etc.). Si vous utilisez le point de terminaison de configuration, assurez-vous que la découverte automatique est activée (nécessite une installation supplémentaire sur le serveur - ElastiCache Cluster Client pour PHP). S'ils ne sont pas activés, vos nœuds ne seront pas résolus correctement, provoquant des problèmes comme celui-ci.

    Il s'avère que c'est le cas pour moi. J'ai essayé d'enregistrer des messages sur les sessions start, regenerate et destroy et avec le pilote de fichier, la régénération se produit, alors qu'avec memcached, il n'appelle même rien d'autre que session_start() aucune fonction autre que . Après quelques recherches, j'ai décidé de revérifier l'hôte et je suis tombé sur Ceci guide dans AWS session_start() 之外的任何函数。经过一番调查后,我决定重新检查主机并偶然发现 这个AWS 中的指南。事实证明,在问题开始时,第二个节点已添加到我们的 Memcached 集群中,但我们一直在使用配置端点,而没有设置此 自动发现。我根本不确定设置是如何工作的。因此,我将 $config['sess_save_path']. Il s'avère que lorsque le problème a commencé, le deuxième nœud a été ajouté à notre cluster Memcached, mais nous utilisions le point de terminaison de configuration sans définir ceci Découverte automatique

    . Je ne sais pas du tout comment fonctionne la configuration. J'ai donc remplacé $config['sess_save_path'] par le point final de l'un des nœuds et le problème a disparu. Cette solution devrait fonctionner jusqu'à ce que j'installe et configure les modules requis, et tant que le nœud reste inchangé. 🎜

    répondre
    0
  • Annulerrépondre