Zend FR

Je suis aussi intéressé par la problématique liée aux cookies telle que tu l'évoques.

Ceci dit, je ferais à ton problème une réponse simplement logique :

-Soit ton utilisateur entre son identifiant et son mot de passe (chiffré dans ta BDD) qui sont corrects, donc il est considéré comme identifié et connecté.

-soit tu le reconnais grâce à une clé stockée dans un cookie. Donc tu fais confiance à cette clé, dans ce cas à quoi bon utiliser le vrai mot de passe de l'utilisateur ?

Dans ce cas tu utilises une table purement interne, avec les identifiants des utilisateur et le même mot de passe pour tous, sachant que cette table n'est JAMAIS utilisée pour une connexion passant par un formulaire de saisie de l'identifiant et du mot de passe.

Donc cette table interne est réservée à la connexion automatique par le seul élément de "confiance", la clé numérique contenue dans le cookie.

Quand il y a du paiement en ligne cette identification automatique par cookie est à prendre avec précaution...

Moi j'ai fais un système à la main qui relogue à  partir de hash conservés dans les cookies.
C'est facile a dire, et pas trop à faire

Guillhomme a écrit:

tu dois pouvoir retrouver la session sur le serveur

Ben non en fait, il faut recréer une session car PHP, par défaut, vire les sessions au bout de 24 minutes (1440 secondes). 1440 est la valeur par défaut de session.gc_maxlifetime. Je pourrais augmenter cette valeur, mais j'ai peur que ce soit un problème de sécurité.

En relisant plusieurs fois c'est assez clair. Je vais tenter de voir ça.

neojick a écrit:

Il n'y a pas de paiement, bien entendu.

Je veux que le visiteur se connecte, et puisse ensuite rester connecté, donc session recréée grâce au cookie si elle a expirée.

Personnellement j'utilise cette méthode pour maintenir la session et dans chacun de mes controllers :

function preDispatch() 
{
    if (Zend_Auth::getInstance()->hasIdentity()) 
    {
        $authSession = new Zend_Session_Namespace('Zend_Auth');
        $authSession->setExpirationSeconds(3600);
        $this->ident = Zend_Auth::getInstance()->getIdentity();
    }
    else 
    {
        $this->logger->debug('ident est false');
        $this->ident = false;
    }
}

je ne sais pas si je suis dans le vrai, mais même après 45 minutes d'inactivité, la session est toujours active.
Il ne semble donc pas que la limite de 1440 secondes soit une limite problématique.

Au delà d'une heure d'inactivité l'utilisateur doit se reconnecter, vu que je n'ai pas fait le choix des cookies.

Ce qui confirme qu'en effet le mot de passe n'est pas utile pour un "auto-login".

C'est mieux d'avoir 2 clé qu'une... qui sait...

Mr.MoOx a écrit:

Ce qui confirme qu'en effet le mot de passe n'est pas utile pour un "auto-login".

C'est mieux d'avoir 2 clé qu'une... qui sait...

Je suis de ton avis, mais si le cookie ne te donne comme information d'identification qu'une clé que tu as créée et un identifiant, mais ne contient pas le mot de passe, tu peux tout aussi bien tester l'age du capitaine sans être plus avancé qu'en testant un mot de passe que l'utilisateur ne vient pas de te donner.

Mais bon c'est pas le débat...

Tu n'a pas un traitement ajax qui se relance tout seul qui réactive la session ?

Sinon de mon côté j'ai quasiment terminé de mettre en place l'idée de Mr.MoOx, il me reste seulement à réfléchir à un bon encryptMoiMaValeurMaisQueJePuisseLaDecrypterStp();

Hello,

Tu n'utilises pas un ini_set('session.save_path', 'mon/dossier/perso') ?

Je crois avoir lu mais je voudrais pas dire une connerie que quand tu fais ça, le nettoyeur de PHP ne fonctionne plus et c'est à toi de gérer ton dossier de sessions et donc la destruction des sessions inactives.

Edit : je viens de trouver où je l'avais lu, c'est tout simplement dans le php.ini

; NOTE: If you are using the subdirectory option for storing session files
;       (see session.save_path above), then garbage collection does *not*
;       happen automatically.  You will need to do your own garbage
;       collection through a shell script, cron entry, or some other method.
;       For example, the following script would is the equivalent of
;       setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
;          cd /path/to/sessions; find -cmin +24 | xargs rm

A+

Dernière modification par mikaelkael (27-10-2008 13:04:58)

Logiquement la session devrait être détruite au bout de 1440sc d'inactivité il me semble.

neojick a écrit:

Logiquement la session devrait être détruite au bout de 1440sc d'inactivité il me semble.

Oui mais donc ce code executé dans les init() de tous les controllers :

$authSession = new Zend_Session_Namespace('Zend_Auth');
$authSession->setExpirationSeconds(3600);

qui pour moi semble fonctionner, ne devrait pas être efficace.
Donc dans quel cas ce code est utile si ce n'est pour régler le temps qui doit s'écouler sans action de l'utilisateur avant expiration ?

Jean-Marc Rigade a écrit:

neojick a écrit:

Logiquement la session devrait être détruite au bout de 1440sc d'inactivité il me semble.

Oui mais donc ce code executé dans les init() de tous les controllers :

Code:

$authSession = new Zend_Session_Namespace('Zend_Auth');
$authSession->setExpirationSeconds(3600);

qui pour moi semble fonctionner, ne devrait pas être efficace.
Donc dans quel cas ce code est utile si ce n'est pour régler le temps qui doit s'écouler sans action de l'utilisateur avant expiration ?

Je sais pas du tout. Je commence à tout mélanger là. La durée de la session côté navigateur, côté serveur. Étant en plus malade aujourd'hui, je passe mon tour pour réfléchir là dessus maintenant.