Utilisation de sfSessionStorage dans Symfony

24.08.2009  • Samuel Breton

sfSessionStorage fait partie des fonctionnalités du Framework qui restent un brin obscures lorsqu’on commence avec Symfony. Mais il s’avère par la suite très utile, que ce soit dans le cadre de la production ou même du développement.

A quoi ça sert ?

Tout simplement à la gestion des cookies de session.

pourquoi l’utiliser ?

Récemment j’ai du développer un projet qui contenait plusieurs applications, 3 pour commencer et elles peuvent se multiplier par la suite. Cela n’a rien de choquant tous les projets on généralement un minimum de 2 applications, un backend et un frontend.
Ce qui peut s’avérer très vite ennuyeux, en effet pour peu que l’on souhaite être connecté en tant qu’admin sur notre backend et en tant qu’utilisateur lamda sur notre frontend, il va falloir se déconnecter assez souvent, ce qui a la longue devient fastidieux.

C’est là qu’intervient notre sfSessionStorage.

Comment le configurer ?

Ce qui est intéressant dans l’utilisation des cookies de session c’est leur simplicité d’utilisation grâce au framework. Pour cela il va falloir modifier le fichier factories.yml.

# apps/frontend/config/factories.yml

all:
#début de ma config
  storage:
    class: sfSessionStorage
    param:
      session_name: frontend

# apps/backend/config/factories.yml

all:
#début de ma config
  storage:
    class: sfSessionStorage
    param:
      session_name: backend

Je me retrouve désormais avec des cookies différents pour chaque application ce qui va me permettre de me connecter sur chacune de mes applications avec des utilisateurs différents.

Autres cas pratiques

On peut bien évidemment étendre cette solution sur les environnements. En effet on peut avoir besoin d’être connecté sur une même application avec deux types d’utilisateurs. Imaginons que j’ai besoin de tester sur mon frontend les différents crédentials que j’ai ajouté à mon application. Je peux me créer des environnements pour chacun de ces crédentials comme par ex : rédacteur et administrateur.
Je vais de nouveau modifier mon fichier factories.yml et le champs d’application ne va plus se faire sur toute l’application mais sur un environnement.

redac:
  storage:
    class: sfSessionStorage
    param:
      session_name: redacteur
admin:
  storage:
    class: sfSessionStorage
    param:
      session_name: administrateur

Dans un soucis de simplicité j’ai raccourci le nom des environnements. Il me faut pour terminer créer mes deux environnements. Je vais pour cela créer les fichiers frontend_redac.php et frontend_admin.php dans le dossier web qui contiendront :

// environnement redac
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'redac', true);
sfContext::createInstance($configuration)->dispatch();

// environnement admin
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'admin', true);
sfContext::createInstance($configuration)->dispatch();

Je pourrai maintenant être connecté sur mon application avec 2 comptes différents.

L’utilisation de la classe sfSessionStorage peut donc s’avérer très utile comme je l’ai dis plus tôt dans un cadre de développement pour faciliter la navigation entre les différentes configuration que l’on peut retrouver sur notre application quant à son utilisation en production chacun fera en fonction de ses besoins bien évidemment.

Mais quand on voit la simplicité de la mise en place il serait dommage de s’en passer.

Directeur conseil chez Spiriit
J'accompagne nos clients sur la mise en place de la stratégie, de l'architecture et dans la structuration du projet. J'interviens en amont des projets pour la planification et en aval sur la partie KPI / Performance.
Voir l’étude de cas
Lire l’article
Lire l’actualité
En savoir plus
En savoir plus
Voir le témoignage
Fermer