10
votes

Les sessions de Coundigniter meurent

Après un peu d'utilisation (25 minutes - 1,5 heure) dans mon système, les utilisateurs expérimentent un coup de pied. Pour une raison quelconque, mes sessions sont une sorte de teinture. Je pense que le cookie du côté du client perd en quelque sorte l'ID de la session et en crée une nouvelle. Je sauve mes données de session sur base de données .

Ceci est ma session Conf: xxx

maintenant, quand je regarde dans la db je vois plusieurs sessions pour chaque utilisateur. Chaque coup de pied signifie une nouvelle session et la vieille session n'est pas supprimée tant qu'elle expire. Lorsque la session "déstabilise" les utilisateurs doivent se connecter à nouveau.

Toute demande d'aide Ceci sera apprécié.

EDIT:

Donc, après quelques recherches, j'ai remarqué que les sessions meurent parce que le session_id qui est enregistré dans le cookie et le session_id enregistré dans la base de données ne correspond pas. Je soupçonne que cela se produit lorsque l'utilisateur charge 2 pages sur un langage / fenêtre différent. Une charge se produit juste lorsque la session met à jour le session_id et la deuxième charge (qui tue la session) avec l'ancien session_id . Le système recherche la session dans la base de données et ne le trouve pas. Résultat: Kick de l'utilisateur System + MAD.

Quelqu'un a-t-il vécu cela? Et quelqu'un a-t-il une idée sur la façon de résoudre ce problème?


4 commentaires

Depuis que vous avez sess_match_ip défini sur true - avez-vous vérifié si leur adresse IP est toujours la même?


Je suis d'accord avec @cbroe - je changerais sess_match_ip sur false. Je le laisse toujours aussi faux et je n'ai jamais expérimenté ce genre de problème. La plupart de vos utilisateurs vont presque certainement utiliser des adresses IP dynamiques (encore plus si elles y accèdent via des appareils mobiles) afin que vous ne deviez pas compter sur la correspondance de l'adresse IP.


@Cbroe - Je viens de changer récemment sess_match_ip pour essayer de vous débarrasser de ce problème. @Matthew - Il s'agit d'une application de bureau et la plupart de mes utilisateurs (90%) utilisent des IP statiques.


Avez-vous essayé de déboguer la classe CI_SESSION ou activant la journalisation de voir si CI commence intentionnellement de nouvelles sessions? Si c'est le cas, vous pouvez probablement reculer de là pour déterminer ce qui se passe.


7 Réponses :


-1
votes

Vous pouvez utiliser le code PHP de base xxx


3 commentaires

et pour le codédiciteur, je pense que vous devez mettre les deux


Ceci est une erreur. Le système de session de Coundigniter n'utilise pas du tout des sessions indigènes de PHP.


Bien que cela soit incorrect cependant, nous pouvons utiliser des sessions autochtones avec CI ... :)



4
votes

Réponse courte.

Ne démarrez pas la session à plusieurs instances. Vérifiez-vous pour ceux existants, si nous parlons de l'autorisation, choisissez l'utilisateur à la page Authlogin si la session n'existe pas . Créez une classe d'authentification / une bibliothèque et laissez-la gérer les choses. Si la session n'existe pas, il demandera de créer une autre.

Ce ne sont pas des sessions multiples, l'ID de session unique est une chaîne aléatoire statistiquement avec une entropie très forte, hachée avec MD5 pour la portabilité et régénéré (Par défaut) toutes les cinq minutes)

- Vérifier ici sous Comment fonctionnent les sessions?

Lorsque vous effectuez Session_Destroy, il détruit des sessions (multiples ou célibataires) liées à l'utilisateur, à partir de la base de données et expire également le cookie. Oui, mauvais design, je sais!

de votre modification de la question

Ainsi, après quelques recherches, j'ai remarqué que les sessions meurent parce que la session_id qui est enregistrée dans le cookie et la session_id qui est enregistré dans la base de données ne correspond pas. Je soupçonne que cela se produit quand L'utilisateur charge 2 pages chacune sur un langage / fenêtre différent. Une charge arrive juste lorsque la session met à jour la session_id et la seconde Charge (qui tue la session) avec l'ancien session_id. Le système Recherche de la session dans la base de données et ne le trouve pas.

Page d'ouverture dans plusieurs onglets = Actualiser sur un seul onglet.

Définissez-vous des sessions sans vérifier leur existence? S'il vous plaît partagez votre script.

Je garderai un œil sur cette réponse jusqu'à ce que nous ayons compris cela.

Oui, j'ai eu un problème similaire, il s'est avéré que je pouvais définir des sessions sans Vérification s'ils existaient déjà et à chaque fois, je les ai créés, ils ont écrasé la session (cookie) dans le navigateur et créé une autre ligne dans la base de données. On dirait que vous êtes confronté au même problème?

laid hack

Définissez ceci comme votre configuration: xxx

Ceci est un problème unique ... Toutefois, sur l'analyse de cette session correspondant à la base de données, il indique clairement que sur sess_time_to_update, la base de données peut ne pas mettre à jour l'ID correspondant ... Cette solution serait toujours une hypothèse à moins que vous n'essayiez.


13 commentaires

Que voulez-vous dire définissez-vous des sessions sans vérifier leur existence? ? Une session est créée (si cela n'existe pas déjà) lorsque le site Web est chargé et s'il n'a pas d'indicateur connecté, l'utilisateur sera dirigé vers un formulaire de connexion. Sur la connexion, j'insère mes données pertinentes dans la session. Pour ce faire, j'exécute simplement: $ ceci-> session-> set_userdata ($ utilisateur); et pour vérifier si j'ai une session en direct, je fais simplement: si (! $ This-> Session-> userData ("enregistré")) . Cela semble très simple et ne semble pas être échoué. Je n'ai pas compris quel code tu voulais que je partage de partager.


Hmmm ... vous question concerne l'authentification de l'utilisateur et le garder stable ... Beaucoup d'entre nous ont travaillé sur CI et ça fonctionne bien avec tous, ce qui signifie que CI Core n'a pas de problèmes ... Ainsi, s'il y a Une erreur, il doit être dans votre code, où vous vous authentifiez ... Avez-vous joué avec $ ceci-> session-> all_userdata () et vérifié?


De plus, si vous n'êtes pas sceptique, j'aimerais voir votre config.php, n'hésitez pas à supprimer des pièces qui ne sont pas censées être visualisées publiquement.


La partie de session de mon config.php est déjà affichée dans la question, quelle partie êtes-vous intéressé? De plus, les presses d'authentification fonctionnent, j'ai ajouté une journalisation à la session.php noyau pour voir où elle meurt et meurt toujours à sess_read () sur la vérification de la base de données si ($ Query-> num_Rows () == 0) . Pourrait-il être dû à charger une base de données secondaire $ db2 = $ ceci-> load-> base de données ($ config, true); ?


Ahhh, maintenant nous touchons la base! Oui mate ... cela a à voir avec la base de données secondaire. Nous pouvons simplement diagnostiquer et évaluer ... Combien de bases de données énorme est cette application?


J'ai une base de données ma principale (contient cI_sessions) qui est toujours $ ceci-> dB et j'ai beaucoup d'autres (8k) qui sont toujours appelés comme si $ dbx = $ this-> charger -> Base de données ($ config, true); . J'ai fait des tests avec le chargement de différents DBS A et depuis la DB principale et je ne pouvais pas recréer cette session de détacher.


Attendez ... Je suppose que j'ai mal compris votre commentaire, dis-tu, les sessions sont stockées dans plusieurs bases de données? S'il vous plaît ré-expression.


Mes sessions sont stockées sur une base de données sur 1, c'est la base de données configurée dans le fichier base de données.php sous Config Dossier comme 'défaut' . Le reste de mes connexions sont dynamiques.


La base de données est donc configurée correctement pour les sessions ... Essayé de désactiver le cache?


Je n'ai jamais permis de mettre en cache donc je ne suis pas sûr de savoir comment je voudrais le désactiver ... CI Documentation Les discussions sur l'activation de sorte que je suppose que ce n'est pas automatiquement activé.


Si la sécurité n'est pas une préoccupation, je recommanderais désactivé ['sess_time_to_update'] dans votre config ... elle génère toutes les 5 minutes à des fins de sécurité ...


Si vous voulez que nous puissions proposer cela pour discuter dans les 15 prochaines minutes ... Que disent?


La sécurité est un problème et si vous avez le temps de discuter ce serait génial :) merci



0
votes

Pourquoi n'essayez-vous pas ceci:

  1. Vérifiez si l'utilisateur a une session active si la session est active = rien pour faire tout va bien

    Maintenant si l'utilisateur n'a pas de session active, vous devez faire 2 choses

    1. Obtenez les cookies de l'utilisateur et s'il y a des cookies, vous rendez la session recommencer et que l'utilisateur ira bien et connecté directement avec en fonction des cookies qu'il a

      b. Si la session n'est pas active et qu'il n'y a pas de cookies, vous devez le prendre à la page de connexion

      Voici un exemple xxx

      dans l'exemple ci-dessus L'heure d'expiration est définie sur un mois (60 sec * 60 min * 24 heures * 30 jours).

      Ok maintenant, vous devez obtenir les cookies xxx

      C'est ça et vous devez l'organiser avec votre propre code, mais c'est la méthode pour la faire!

      Remarque: Assurez-vous sur la déconnexion de l'utilisateur pour effacer les cookies afin qu'il ne puisse effacer " T Login automatique à nouveau.


2 commentaires

Cela signifie écrire la classe de session à partir de zéro et c'est un problème. Codedigniters Class me donne tout ce dont j'ai besoin, plus j'ai besoin des sessions pour être stockées dans la base de données pour les statistiques de déconnexion et d'utilisation à distance.


Pas besoin de l'écrire, vous pouvez appeler la classe à l'intérieur du Si je vous ai donné le code de base pour commencer et c'est une bonne méthode pour commencer, mais vous devez la modifier comme il convient à votre code.



1
votes

Je suis aussi un développeur de codeigniter. J'ai également appliqué ci-dessous Code dans mon application: -

1) opening application in firefox mozilla at 10:55 pm then it will take You in login screen at 11:00 pm.

2) at the same time , opening application in chrome browser at 10:56 pm  then it will take You in login screen at 11:05 pm.


1 commentaires

@Dvir Levy est-ce qui vous aide?



0
votes

J'ai eu le même problème, cet état de configuration a finalement aidé: xxx

sess_time_to_update doit être identique à sess_expiration

sess_encrypt_cookie doit être faux < / p>


0 commentaires

0
votes

de Les docs sous Comment les sessions travailler? strong>

Lorsqu'une page est chargée, la classe de session vérifiera s'il est valable. Les données de session existent dans le cookie de session de l'utilisateur. Si des sessions données n'existe pas (ou s'il a expiré) une nouvelle session sera créée et sauvé dans le cookie. Si une session existe, ses informations vont Soyez mis à jour et le cookie sera mis à jour. Avec chaque mise à jour, le session_id sera régénéré. P> blockQuote>

Avez-vous essayé d'utiliser la fonction de journalisation du code allumeur pour voir si le module de session crée des nouvelles sessions? Plus précisément, vous voulez probablement faire du débogage contre la classe CI_Session STRAND> System / Bibliothèques / Session.php em>). P>

Il y a 2 taches dans SESES_RELAD CODE> Lorsque CI déterminera qu'il n'y a pas de session en cours. Si vous activez la journalisation, par les docs , vous pouvez voir si CI est Frapper ces conditions P>

CI_Session :: sess_read (condition 1) h2> xxx pré>

CI_Session :: sess_dread (condition 2) h2>
// encryption was not used, so we need to check the md5 hash
$hash    = substr($session, strlen($session)-32); // get last 32 chars
$session = substr($session, 0, strlen($session)-32);

// Does the md5 hash match?  This is to prevent manipulation of session data in userspace
if ($hash !==  md5($session.$this->encryption_key))
{
    log_message('error', 'The session cookie data did not match what was expected. This could be a possible hacking attempt.');
    $this->sess_destroy();
    return FALSE;
}  


3 commentaires

Je suis connecté et les sessions MT sont détruites sur cette condition: // pas de résultat? Tue le! Si ($ Query-> Num_Rows () == 0) Je ne peux pas mettre mon doigt sur ce qui est cousin ça ...


C'est génial, alors vous savez où regarder. Lecture via le code On dirait qu'il n'y a pas de résultats correspondants dans la base de données. Peut-être que vous appelez sess_destroy ailleurs à la main? Vous voudrez peut-être essayer d'en développer les messages du journal pour déterminer le problème. Je vous ai invité à discuter si vous voulez essayer de travailler un peu aujourd'hui.


Lien pour discuter. Si quelqu'un d'autre sur ce fil veut, faites le moi savoir.



0
votes

J'avais le même problème à exécuter plusieurs applications sous une installation CI. Après plusieurs heures de ligne par ligne de débogage en ligne à l'aide de Xdebug, j'ai constaté que chaque application à CodeCIiter avait sa session distincte. Pour résoudre l'erreur, j'ai fourni un nom distinct dans chaque fichier config.php.

Fichier un, P>

$config['sess_cookie_name']     = 'ci_session3';


0 commentaires