probleme de duree de session

[Nicolas Longuet]

bonjour,

Dans le meme projet, nous avons 4 applications:
- 1 aplli. a une duree de session 1800
- et les 3 autres 3600.

déjà la il y a un problème car rien n'est configure dans le fichier
setting.yml et factory.yml.

nous avons configurer les fichiers suivant pour allonger les sessions
a 86400... et la!! surprise toutes nos applications sont revenu à
1800.

donc nous avons teste pour mettre la session a 1200.... mais rien y
fait, et toutes nos applis sont désormais bloquées sur 1800.

dans php.ini la valeur est a 86400.

si quelqu'un a une solutions pour sf 1.4

[chok]

Si tu peux dans factories.yml :p

http://www.symfony-project.org/reference/1_4/fr/05-Factories#chapter_05_sub_les_parametres_de_session_set_cookie_params

[nicolas longuet]

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--- donc sa doit venir de la je pense.

quand je fais un:
ini_set('session.gc_maxlifetime', 86400);

et
ini_get('session.gc_maxlifetime') affiche bien 86400

MAIS symfony lui ne veut rien savoir et reste a 1800.

!!! y a bien quelqu'un qui a voulu augmente sa durée de session quand même (avec sfGuardSecurityUser) !!??

[chok]

Si j'ai bien compris, le timeout permet de desuathentifier
l'utilisateur et est interne à symfony. gc_maxlifetime et le timeout
ne sont pas lié :

http://www.symfony-project.org/reference/1_4/en/05-Factories#chapter_05_sub_timeout

Il y a une raison particulière pour ne pas supprimer la session ?
Sinon vous pouvez essayer ca :

storage:
class: sfSessionStorage
param:
session_name: symfony
session_cookie_lifetime: 3600

Il faut faire attention a ne pas relier les sessions des différentes
applications puisque a prioriri la session n'est pas partagé si elle
n'a pas la meme durée de vie. Donc a priori, vous devriez utilisez des
sous domaines différend(ou path) et le spécifier dans la session avec
le parametre session_cookie_domain(ou session_cookie_path)

[chok]

j'avais pas trop réflechi au problème :p

Mais c'est pour ca que vous utilisez le timeout et pas la session.

Et en fait j'avais mal lu :

To avoid unexpected behavior, the user class automatically forces the
maximum lifetime for the session garbage collector
(session.gc_maxlifetime) to be greater than the timeout.

donc ca supprime la session de toute facon et sur
http://www.manuelphp.com/php/ini.session.gc-maxlifetime.php:

Si des scripts différents ont des valeurs différentes de
session.gc_maxlifetime mais partagent le même endroit pour y stocker
les données de session, alors, le script dont la valeur est la plus
petite effacera la donnée.

Donc à priori, il va falloir utiliser des sessions différentes comme
expliqué plus haut

On 29 mai, 01:36, chok <chok...@gmail.com> wrote:
> Si j'ai bien compris, le timeout permet de desuathentifier
> l'utilisateur et est interne à symfony. gc_maxlifetime et le timeout
> ne sont pas lié :
>

> http://www.symfony-project.org/reference/1_4/en/05-Factories#chapter_...

[nicolas longuet]

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 inactif après 1800 secondes d'inactivité.

//factories.yml//////////////////
prod:
  storage:
   class: sfSessionStorage
   param:
     session_name: sf_site_web
     session_cookie_lifetime: 86400

user:
  class: myUser
  param:
    timeout:         86400

//----
et le php.ini est à 86400

//----
DONC ma question est simple:
comment changer la valeur TIMEOUT qui se trouve dans la BARRE DEBUG quand on clic sur CONFIG

options:
  auto_shutdown: true
  culture: null

  default_culture: en
  use_flash: false
  logging: false

  timeout: 1800 <---  faut changer sa mais COMMENT.

merci

[chok]

Vous ne pouvez pas partager une session entre plusieurs applications
avec des durées différentes.

La solution utilisé des sessions différentes :

Application 1 :

prod:
storage:
class: sfSessionStorage
param:

session_name: app_1
session_cookie_domain: app1.site.com #normalement pas nécessaire
le session_name devrait suffire

session_cookie_lifetime: 86400

user:
class: myUser
param:
timeout: 86400

Application 1 :

prod:
storage:
class: sfSessionStorage
param:

session_name: app_2
session_cookie_domain: app2.site.com #normalement pas nécessaire
le session_name devrait suffire

session_cookie_lifetime: 86400

user:
class: myUser
param:

timeout: 3400

Par contre vous ne partagez plus aucune informations de la session
donc vous devrez vous logguez sur chaque session indépendament.

Si vraiment c'est nécessaire de partager la session, ca devient
nettement plus compliqué :p

Il faudrait surcharger le User pour que les credentials,
authentification.... utilise des namespace différent par exemple.
Comme ca vous auriez la meme session mais vous utiliserez des
informations différentes de connexion pour chaque application.

Dans cette surcharge, il faudrait également vérifié que vous vous êtes
connecté sur une autre application et vous connecté automatiquement
sur l'autre.


Je sais pas si j'ai été clair ? :p

[nicolas longuet]

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: sf_site_web

     session_cookie_lifetime: 7200

  user:
    class: myUser
    param:
      timeout: 7200


et....  rien ne se passe de plus; mais d'ou vient le 1800!!!! la configuration ne prend rien en compte.
c assez problématique. les utilisateurs ne vont pas aimer se faire déconnecter comme sa.

la myUser() est derivé de sfGuardSecurityUser()
sa ne viendrait pas de la le problème?

j'ai supprimer tout les cookies de mon navigateur aussi.

[chok]

C'est dans la debug bar de l'application en question que ca affiche
1800 ?

Bizarre en effet. symfony cc peut être :D

Sinon à ce que je vois la gestion du timeout est géré dans
sfBasicSecurityUser. Avec des options passé a intialize. Il faudrait
voir si quelque part ces options ont été modifiés avant cet appel

[nicolas longuet]

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->isAuthenticated())
    {
      // remove user if timeout
      $this->getAttributeHolder()->removeNamespace('sfGuardSecurityUser');
      $this->user = null;
    }
  }

y a peu être une piste ici.

[nicolas longuet]

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, sfStorage $storage, $options = array()){
        $option['timeout'] = false;

        parent::initialize($dispatcher, $storage, $options);
}

voila, franchement il aurait pu le marquer quelque pars, ou faire en sorte que sa marche directement avec le plugin.

[Olivier LOYNET]

C’est la valeur max dans php.ini qu’il faut augmenter

 

Olivier

 

 

---

De : symfo...@googlegroups.com [mailto:symfo...@googlegroups.com] De la part de nicolas longuet
Envoyé : lundi 31 mai 2010 13:12
À : symfo...@googlegroups.com
Objet : Re: [symfony-fr] Re: probleme de duree de session

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Symfony-fr.
Pour envoyer un message à ce groupe, adressez un e-mail à symfo...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse symfony-fr+...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/symfony-fr?hl=fr

[nicolas longuet]

euh, il faut lire le topic en entier.

la valeur dans le php.ini était déjà augmentée

:)

sa marche maintenant ouf