Utilisation avancée
Même si les exemples de l'utilisation basique sont une manière parfaitement acceptable
d'utiliser les sessions dans Zend Framework, il existe de bonnes pratiques à considérer.
Cette section détaille plus finement le traitement des sessions et présente des utilisations
plus avancées du composant Zend_Session.
Démarrer une session
Si vous voulez que toutes les requêtes aient une session facilitée avec
Zend_Session, alors démarrez la session dans votre fichier
d'amorçage :
Démarrer la session globale
En démarrant la session dans votre fichier d'amorçage, vous empêcher la
possibilité de démarrer votre session après l'envoi d'en-têtes à votre navigateur, ce
qui entraîne la levée d'une exception, et peut être une page cassée pour les visiteurs
de votre site. Divers usages avancés nécessitent premièrement
Zend_Session::start(). (D'autant plus sur les utilisations
avancées suivantes.)
Il existe quatre manières différentes pour démarrer une session, quand on utilise
Zend_Session. Deux sont mauvaises.
Mauvaise : n'activez pas session.auto_start
de PHP. Si vous n'avez pas la possibilité de désactiver ce réglage dans le
php.ini, ou que vous utilisez mod_php (ou équivalent), et que le réglage est
déjà activé dans le php.ini, alors ajoutez le code suivant à votre
fichier .htaccess (habituellement votre dossier de démarrage HTML)
:
Mauvaise : n'utilisez pas la fonction session_start()
directement. Si vous utilisez directement session_start(), et que
vous démarrez en utilisant Zend_Session_Namespace, une
exception sera levée par Zend_Session::start() ("session
has already been started"). Si vous appelez session_start(), après
avoir utilisé Zend_Session_Namespace ou démarré
explicitement Zend_Session::start(), une erreur de niveau
E_NOTICE sera générée, et l'appel sera ignoré.
Correcte : utilisez Zend_Session::start(). Si vous
voulez que toutes vos requêtes aient et utilisent les sessions, alors placez
cette fonction le plus tôt possible et sans condition dans votre fichier
d'amorçage. Les sessions ont un coût. Si certaines requêtes nécessitent les
sessions, mais que les autres n'en ont pas besoin, alors :
Sans conditions, réglez l'option strict à
TRUE en utilisant
Zend_Session::setOptions() dans votre fichier
d'amorçage.
Appelez Zend_Session::start(), uniquement
pour les requêtes qui nécessitent l'usage des sessions, avant la
première instanciation d'un objet
Zend_Session_Namespace().
Utilisez "new Zend_Session_Namespace()" normalement,
quand nécessaire, mais faites attention que
Zend_Session::start() soit appelée
auparavant.
L'option strict empêche new
Zend_Session_Namespace() d'automatiquement démarrer une session en
utilisant Zend_Session::start(). Ainsi, cette option aide
les développeurs d'application Zend Framework universelles à imposer une
décision de conception afin d'empêcher l'utilisation de sessions pour certaines
requêtes, puisqu'une erreur sera levée en utilisant cette option et en
instanciant Zend_Session_Namespace, avant un appel
explicite de Zend_Session::start(). N'employez pas cette
option dans le code de la librairie coeur du ZF, car seuls les développeurs
universels peuvent faire ce choix de design. Les développeurs doivent considérer
avec précaution l'impact de l'utilisation de
Zend_Session::setOptions(), puisque ces options ont un
effet global, suite à leur correspondance avec les options sous-jacentes pour
ext/session.
Correcte : instanciez simplement
Zend_Session_Namespace() quand nécessaire, la session PHP
sous-jacente sera automatiquement démarrée. Ceci permet un usage extrêmement
simple qui fonctionne dans la plupart des cas. Cependant, vous êtes responsable
de vous assurer que le premier new Zend_Session_Namespace()
intervient avant que toute sortie (par exemple en-têtes HTTP) ait été envoyée par
PHP au client, si vous utilisez le réglage par défaut, sessions basées sur les
cookies (fortement recommandé). Voir
cette section pour plus
d'informations.
Verrouiller les espaces de noms de session
Les espaces de noms de session peuvent être verrouillés, pour éviter tout risque
d'altération des données dans cet espace. Utilisez lock() pour attribuer à
un espace de nommage spécifique le mode lecture seule,unLock() pour
attribuer le mode lecture / écriture, et isLocked() pour tester si un
espace de nommage a été auparavant verrouillé. Les verrouillages sont transitoires et ne
persistent pas d'une requête à l'autre. Verrouiller un espace de nommage n'a pas d'effet
sur les méthodes de réglages des objets stockés dans cet espace, mais empêche
l'utilisation des méthodes de réglage de l'espace de noms destiné à détruire ou à
remplacer les objets stockés dans l'espace. De la même manière, verrouiller les
instances Zend_Session_Namespace n'empêche pas l'accès direct à
l'alias dans tableau de stockage $_SESSION (voir PHP references).
Verrouillage des espaces de noms de sessionlock();
// dévérrouillage si déjà vérrouillé
if ($userProfileNamespace->isLocked()) {
$userProfileNamespace->unLock();
}
]]>Expiration d'un espace de noms
Des limites peuvent être affectées à la durée de vie soit des espaces de noms soit
de clés individuelles dans cet espace. Les cas d'utilisation habituels incluent le
passage d'une information temporaire entre requêtes, et la diminution de l'exposition à
un potentiel risque de sécurité par la suppression de l'accès à des informations
sensibles potentielles à une certaine heure après que l'authentification ait eu lieu.
L'expiration peut être basée sur les secondes écoulées, ou basées sur le concept de
"hops", où un "hop" apparaît à chaque requête successive.
Exemple d'expirationa = 'apple';
$s->p = 'pear';
$s->o = 'orange';
$s->setExpirationSeconds(5, 'a');
// expire seulement pour la clé "a" dans 5 secondes
// expiration de tout l'espace de nommage dans 5 "hops"
$s->setExpirationHops(5);
$s->setExpirationSeconds(60);
// L'espace de noms "expireAll" sera marqué "expired"
// soit à la première requête reçue après 60 secondes,
// soit dans 5 hops, en fonction de ce qui arrivera en premier.
]]>
Quand vous travaillez avec des données de session expirées dans la requête
courante, des précautions doivent être prises concernant leur utilisation. Bien que les
données soient retournées par référence, modifier les données expirées ne les rendra pas
persistantes dans la requête courante. Dans le but de remettre à zéro leur temps
d'expiration, transférez les données dans des variables temporaires, utilisez l'espace
de nommage pour les effacer, et ensuite réaffectez les clés appropriées de
nouveau.
Encapsulation de session et Contrôleurs
Les espaces de noms peuvent aussi être utilisés pour séparer l'accès aux sessions
par contrôleur afin de protéger les variables d'une quelconque contamination. Par
exemple, un contrôleur d'authentification pourrait garder ces données de session
séparées de tous les autres contrôleurs pour des raisons de sécurité.
Sessions nommées par contrôleur avec expiration automatique
Le code suivant, partie d'un contrôleur destiné à afficher une question dans
un test, initie une variable booléenne pour représenter l'acceptation ou non d'une
réponse à la question soumise. Dans ce cas, l'utilisateur de l'application a 300
secondes pour répondre à la question affichée.
setExpirationSeconds(300, 'accept_answer');
// expire seulement cette variable
$testSpace->accept_answer = true;
]]>
Ci-dessous, le contrôleur qui analyse les réponses aux questions du test
détermine l'acceptation ou non d'une réponse en se basant sur le fait que
l'utilisateur a répondu dans le temps alloué :
accept_answer === true) {
// dans le temps autorisé
}
else {
// pas dans le temps autorisé
}
]]>Limiter les instances multiples par espace de noms
Bien que le verrouillage de
session fournisse un bon degré de protection contre l'utilisation inattendue des
données dans un espace de noms, Zend_Session_Namespace offre
aussi la possibilité d'empêcher la création d'instances multiples correspondant à un
unique espace de noms.
Pour activer ce comportement, réglez à TRUE le second argument du
constructeur quand vous créez la dernière instance autorisée de
Zend_Session_Namespace. Tout tentative suivante d'instanciation
du même espace de noms entraînera la levée d'une exception.
Limiter l'accès à un espace de noms à une instance uniquefoo = 'bar';
assert($authSpaceAccessor2->foo, 'bar');
try {
$aNamespaceObject = new Zend_Session_Namespace('Zend_Auth');
} catch (Zend_Session_Exception $e) {
echo "Cannot instantiate this namespace "
. "since $authSpaceAccessor2 was created\n";
}
]]>
Le second paramètre dans le constructeur ci-dessus informe
Zend_Session_Namespace que toute future instance avec l'espace de
noms "Zend_Auth" sera refusée. Tenter de créer une instance entraînera la levée d'une
exception par le constructeur. Le développeur devient responsable de stocker quelque
part une référence à l'instance de l'objet ($authSpaceAccessor1,
$authSpaceAccessor2, ou $authSpaceAccessor3 dans l'exemple
ci-dessus), si l'accès à l'espace de noms de session est nécessaire plus tard dans la
même requête. Par exemple, le développeur peut stocker la référence dans une variable
statique , ajouter la référence au registre (voir
Zend_Registry), ou sinon la rendre disponible pour
les autres méthodes qui peuvent avoir accès à cet espace de noms.
Travailler avec les tableaux
A cause de l'histoire de l'implémentation des méthodes magiques dans PHP, la
modification d'un tableau à l'intérieur d'un espace de noms peut ne pas fonctionner avec
les versions de PHP inférieures à 5.2.1. Si vous travaillez exclusivement avec des
versions de PHP 5.2.1 ou supérieur., alors vous pouvez passer la section suivante.
Modifier un tableau de données avec un espace de noms de sessionLe code suivant illustre le problème qui peut être reproduit :array = array();
$sessionNamespace->array['testKey'] = 1;
// ne fonctionne pas comme attendu avant PHP 5.2.1
echo $sessionNamespace->array['testKey'];
]]>Construire les tableaux avant le stockage en session
Si possible, évitez le problème en stockant les tableaux dans un espace de
noms de session seulement après que toutes les clés et les valeurs aient été
définies :
array = array('a', 'b', 'c');
]]>
Si vous utilisez une version de PHP affectée et avez besoin de modifier un tableau
après l'avoir assigné à une clé dans l'espace de noms, vous pouvez utiliser l'une des
solutions suivantes :
Solution : réassigner un tableau modifié
Dans le code suivant, une copie du tableau stocké est créée, modifiée, et
réassignée à la place d'où provenait la copie, en effaçant le tableau
original.
array = array('fruit' => 'pomme');
// copie du tableau
$tmp = $sessionNamespace->array;
// modification de la copie
$tmp['fruit'] = 'poire';
// ré-assignation de la copie dans l'espace de noms
$sessionNamespace->array = $tmp;
echo $sessionNamespace->array['fruit']; // affiche "poire"
]]>Solution : stocker un tableau contenant une référence
Autrement, stockez un tableau contenant une référence au tableau désiré, et y
accéder indirectement.
someArray = array( &$a );
$a['foo'] = 'bar';
echo $myNamespace->someArray['foo']; // affiche "bar"
]]>Utiliser les sessions avec des objets
Si vous prévoyez de rendre persistant des objets dans les sessions PHP, pensez
qu'ils peuvent être sérialisé pour
le stockage. Ainsi, tout objet persistant dans les sessions PHP doit être désérialisé
après sa récupération à partir du stockage. L'implication est que le développeur doit
s'assurer que les classes des objets persistants doivent avoir été définies avant que
l'objet ne soit désérialisé du stockage. Si aucune classe n'est définie pour l'objet
désérialisé, alors il devient une instance de stdClass.
Utiliser les sessions avec les tests unitaires
Zend Framework s'appuie sur PHPUnit pour faciliter ses propres tests. Beaucoup de
développeurs étendent la suite des tests unitaires pour couvrir le code de leurs
applications. L'exception "Zend_Session is currently marked as
read-only" (NDT. : "Zend_Session est actuellement marquée en lecture seule")
est levée lors de l'exécution des tests unitaires, si une méthode d'écriture est
utilisée après la clôture de la session. Cependant les tests unitaires employant
Zend_Session requièrent une attention particulière, car la
fermeture (Zend_Session::writeClose()), ou la destruction d'une
session (Zend_Session::destroy()) empêche tout futur changement
ou suppression de clés dans un Zend_Session_Namespace. Ce
comportement est un résultat direct du mécanisme fondamental de l'extension session et
des fonctions PHP session_destroy() et session_write_close(),
qui n'a pas de mécanisme de marche arrière ("undo") pour faciliter le réglage/démontage
avec les tests unitaires.
Pour contourner ceci, regardez le test unitaire
testSetExpirationSeconds() dans
tests/Zend/Session/SessionTest.php et SessionTestHelper.php,
qui utilise le code PHP exec() pour charger un processus séparé. Le nouveau
processus simule plus précisément une seconde requête successive du navigateur. Le
processus séparé démarre avec une session "propre", comme n'importe quelle exécution de
PHP pour une requête Web. Ainsi, tout changement fait à $_SESSION dans le
processus appelant devient disponible dans le processus enfant, pourvu que le parent ait
fermé la session avant d'utiliser exec().
Utilisation de PHPUnit pour tester le code écrit avec Zend_Session*a = 'abricot';
$s->o = 'orange';
$s->setExpirationSeconds(5);
Zend_Session::regenerateId();
$id = Zend_Session::getId();
session_write_close();
// relâche la session donc le processus suivant peut l'utiliser
sleep(4); // pas assez long pour les éléments expirent
exec($script . "expireAll $id expireAll", $result);
$result = $this->sortResult($result);
$expect = ';a === abricot;o === orange;p === pear';
$this->assertTrue($result === $expect,
"iteration over default Zend_Session namespace failed; "
. "expecting result === '$expect', but got '$result'");
sleep(2);
// assez long pour que les éléments expirent
// (total de 6 secondes écoulées, avec une expiration de 5)
exec($script . "expireAll $id expireAll", $result);
$result = array_pop($result);
$this->assertTrue($result === '',
"iteration over default Zend_Session namespace failed; "
. "expecting result === '', but got '$result')");
session_start(); // redémarre artificiellement une session suspendue
// Ceci peut être découpé dans un test séparé, mais en réalité,
// si quoi que ce soit reste de la partie précédente et contamine
// les tests suivants, alors c'est un bug dont nous voulons avoir
// des informations
$s = new Zend_Session_Namespace('expireGuava');
$s->setExpirationSeconds(5, 'g');
// maintenant essayons d'expirer seulement une clé dans l'espace
$s->g = 'guava';
$s->p = 'peach';
$s->p = 'plum';
session_write_close();
// relâche la session donc le processus suivant peut l'utiliser
sleep(6); // pas assez long pour les éléments expirent
exec($script . "expireAll $id expireGuava", $result);
$result = $this->sortResult($result);
session_start(); // redémarre artificiellement la session suspendue
$this->assertTrue($result === ';p === plum',
"iteration over named Zend_Session namespace failed (result=$result)");
]]>