euh, il faut lire le topic en entier.
la valeur dans le php.ini était déjà augmentée
:)
sa marche maintenant ouf
--
Vous recevez ce message, car vous êtes abonné au groupe Google
Groupes Symfony-fr.
Pour envoyer un message à ce groupe, adressez un e-mail
à symfony...@googlegroups.com.
Pour v
C’est la valeur max dans php.ini qu’il faut augmenter
Olivier
_
De : symfony-fr@googlegroups.com [mailto:symfony...@googlegroups.com] De la
part de nicolas longuet
Envoyé : lundi 31 mai 2010 13:12
À : symfony-fr@googlegroups.com
Objet : Re: [symfony-fr] Re: probleme de duree de
bon g trouver, et c bien un probleme lié à symfony:
pour que vos données ne soit pas court-circuités par symfony lorsque vous
utilisez sfGuardsecuriteUser et le fichier factories.yml
fait:
class myUser extends sfGuardSecurityUser {
public function initialize(sfEventDispatcher $dispatcher,
oui c bien dans le debug barre
lol oui un cc... peut etre qu' a la 100eme fois sa marchera :)
//
la valeur de mon cookie de session a bien changer de nom: donc sa marche.
et pourtant les options 'timeout' ne sont pas pris en compte
//
sinon dans class sfGuardSecurityUser :
if (!$this->isAuth
merci pour ta rapidité :)
donc ce que j'ai fait:
- effacer toutes les infos des fichiers factories.yml de toutes les
applications.
- puis j'ai remit la configuration 'personnalisée' suivante dans une seule
application :
all:
...
storage:
class: sfSessionStorage
param:
session_name: s
Nous ne savons plus quoi faire; quoi que nous fassions, l'application RESTE
SUR 1800
et même les commandes php ni font rien:
- session.gc_maxlifetime ou (symfony.gc_maxlifetime)
- session.-
le PHP prend en compte les changements MAIS symfony ne veut rien savoir et
déconnecte les utilisateurs i
merci mais mon fichier factories.yml est deja renseigne:
user:
class: myUser
param:
timeout: 3600
logging: %SF_LOGGING_ENABLED%
use_flash: true
default_culture: %SF_DEFAULT_CULTURE%
et sa reste a 1800 !
pour info j'utilise ---sfGuardSecurityUser---
