repo_zf1/documentation/manual/fr/module_specs/Zend_Session-GlobalSessionManagement.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: no -->
<sect1 id="zend.session.global_session_management">
    <title>Gestion générale de la session</title>

    <para>
        Le comportement des sessions peut être modifié en utilisant les méthodes statiques de
        la classe Zend_Session. Il s'agit du comportement global des sessions dans toute
        l'application, incluant la configuration des <ulink
        url="http://www.php.net/session#session.configuration">options usuelles offertes par
        ext/session</ulink>, ceci en utilisant <methodname>Zend_Session::setOptions()</methodname>.
        Ainsi, des problèmes de sécurité peuvent apparaître si vous utilisez mal le support de
        stockage des sessions <code>save_path</code> ou encore si vous négligez le cookie utilisé
        par ext/session.
    </para>

    <sect2 id="zend.session.global_session_management.configuration_options">
        <title>Options de configuration</title>

        <para>
            Lors de la création du premier namespace de session, Zend_Session va
            automatiquement démarrer la session <acronym>PHP</acronym>, sauf si celle-ci a été démarrée avec <link
            linkend="zend.session.advanced_usage.starting_a_session"><methodname>Zend_Session::start()</methodname></link>
            auparavant. La session <acronym>PHP</acronym> résultante utilisera les options de configuration par défaut
            de Zend_Session, sauf si ceux-ci ont été modifiés à l'aide de
            <methodname>Zend_Session::setOptions()</methodname>.
        </para>

        <para>
            Pour assigner une option de configuration, passez son nom (la partie qui suit
            "<code>session.</code>" dans les options de configuration de ext/session) comme clé au
            tableau passé à <methodname>Zend_Session::setOptions()</methodname>. La valeur
            correspondante dans le tableau sera alors utilisée comme valeur de l'option. Si vous
            omettez une option, alors celles par défaut recommandées par Zend_Session seront
            utilisées, sinon si elles n'existent pas, les valeurs par défaut de php.ini. Les retours
            et les idées quant aux "options recommandées" sont appréciées et peuvent être envoyées à
            <ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>.
        </para>

        <example id="zend.session.global_session_management.setoptions.example">
            <title>Utiliser Zend_Config pour configurer Zend_Session</title>

            <para>
                Pour configurer le composant en utilisant un objet <link
                linkend="zend.config.adapters.ini"><classname>Zend_Config_Ini</classname></link>,
                ajoutez ces paramètres au fichier <acronym>INI</acronym> en question:
            </para>

            <programlisting language="ini"><![CDATA[
; Paramètres de production
[production]
; bug_compat_42
; bug_compat_warn
; cache_expire
; cache_limiter
; cookie_domain
; cookie_lifetime
; cookie_path
; cookie_secure
; entropy_file
; entropy_length
; gc_divisor
; gc_maxlifetime
; gc_probability
; hash_bits_per_character
; hash_function
; name doit être unique pour chaque application partageant le même nom de domaine
name = UNIQUE_NAME
; referer_check
; save_handler
; save_path
; serialize_handler
; use_cookies
; use_only_cookies
; use_trans_sid

; remember_me_seconds = <integer seconds>
; strict = on|off

; Development hérite de production, mais redéfinit certaines valeurs
[development : production]
; N'oubliez pas de créer ce dossier et d'attribuer à PHP les droits 'rwx'.
save_path = /home/myaccount/zend_sessions/myapp
use_only_cookies = on
; Le cookie de session durera 10 jours
remember_me_seconds = 864000
]]></programlisting>

            <para>
                Ensuite, chargez ce fichier de configuration, et passez sa représentation
                tableau à <methodname>Zend_Session::setOptions()</methodname>:
            </para>

            <programlisting language="php"><![CDATA[
$config = new Zend_Config_Ini('myapp.ini', 'development');

require_once 'Zend/Session.php';
Zend_Session::setOptions($config->toArray());
]]></programlisting>
        </example>

        <para>
            La plupart des options ne nécessitent pas d'explications étant donné qu'elles font
            parti des options de ext/session, documentées dans le manuel officiel de <acronym>PHP</acronym>, cependant
            les options particulières méritent une description: <itemizedlist mark="opencircle">
                    <listitem>
                    <para>
                        bool <code>strict</code> : désactive le démarrage automatique de
                        <classname>Zend_Session</classname> lorsque <code>new
                        Zend_Session_Namespace()</code> est utilisé.
                    </para>
                </listitem>

                <listitem>
                    <para>
                        int <code>remember_me_seconds</code> : temps de vie du cookie de
                        session, une fois le navigateur client fermé.
                    </para>
                </listitem>

                <listitem>
                    <para>
                        string <code>save_path</code> : Cette valeur est dépendante du système
                        sur lequel <acronym>PHP</acronym> est lancé. Un <emphasis>chemin absolu</emphasis> vers un
                        dossier lisible et écrivable à <acronym>PHP</acronym> devrait être utilisé (dans le cas
                        d'utilisation d'un dossier pour le support des sessions). Si le chemin n'est
                        pas pleinement accessible à <acronym>PHP</acronym>, <classname>Zend_Session</classname> lancera
                        une exception à son démarrage (lorsque <methodname>start()</methodname> est
                        appelée.
                    </para>

                    <note>
                        <title>Attention aux failles de sécurité</title>

                        <para>
                            Si le chemin des sessions est accessible en lecture à d'autres
                            applications, alors le vol de session peut être possible. Si le dossier
                            est accessible en écriture à d'autres applications, alors <ulink
                            url="http://en.wikipedia.org/wiki/Session_poisoning">l'empoisonnement de
                            sessions</ulink> peut être possible. SI le chemin est partagé avec
                            d'autres utilisateurs ou d'autres applications <acronym>PHP</acronym>, plusieurs problèmes
                            de sécurité peuvent apparaître, incluant le vol de session, et les
                            collisions de ramasse-miette (garbage collection) (Un process d'une
                            autre application <acronym>PHP</acronym> déclenche une collecte sur vos fichiers de
                            session).
                        </para>

                        <para>
                            Par exemple, un pirate peut visiter le site d'une victime pour
                            obtenir un cookie de session. Il modifie ensuite le chemin du cookie
                            afin que celui-ci soit envoyé à sa propre application (en partage sur le
                            même serveur que le votre), et il exécute
                            <methodname>var_dump($_SESSION)</methodname>. Il obtient alors des informations sur
                            les variables de session que vous stockez, et il peut les modifier pour
                            retourner sur votre site. L'empoisonnement a eu lieu. Même si deux
                            applications sur le même serveur ne partagent pas le même dossier
                            <code>save_path</code>, si celui-ci est devinable, l'attaquant peut
                            alors l'utiliser sur sa propre application et dans certaines
                            configurations de <acronym>PHP</acronym>, accéder à la session de l'application victime. La
                            valeur du <code>save_path</code> ne doit pas être rendue publique ou
                            devinable, le dossier doit se trouver dans un endroit isolé et
                            sécurisé.
                        </para>
                    </note>
                </listitem>

                <listitem>
                    <para>
                        string <code>name</code> - La valeur doit être choisie de manière
                        <emphasis>unique</emphasis> pour chaque application.
                    </para>

                    <note>
                        <title>Risque de sécurité</title>

                        <para>
                            Si la valeur <code>php.ini</code> de <code>session.name</code>
                            n'est pas unique (celle par défaut "PHPSESSID"), et qu'il existe
                            plusieurs applications accessible via le même domaine, alors elle
                            partagerons leurs données pour les visiteurs. Aussi, des problème de
                            corruption peuvent apparaître.
                        </para>
                    </note>
                </listitem>

                <listitem>
                    <para>
                        bool <code>use_only_cookies</code> - Afin d'éviter d'autres failles de
                        sécurité (concernant le trans-sid), ne changez pas cette option. <note>
                                <title>Risque de sécurité</title>

                            <para>
                                Si cette option n'est pas activée, un attaquant peut
                                facilement fixer un id de session d'une victime en lui envoyant des
                                liens tels que
                                <code>http://www.example.com/index.php?PHPSESSID=fixed_session_id</code>.
                                La fixation fonctionne si la victime n'a pas déjà un identifiant de
                                session sur le site example.com. Lorsque la victime utilise un
                                identifiant de session qu'un attaquant connaît, il peut alors se
                                faire passer pour elle.
                            </para>
                            </note>
                        </para>
                </listitem>
                </itemizedlist>
            </para>
    </sect2>

    <sect2 id="zend.session.global_session_management.headers_sent">
        <title>L'erreur: "Headers Already Sent"</title>

        <para>
            Si vous voyez l'erreur, "Cannot modify header information - headers already sent",
            ou, "You must call ... before any output has been sent to the browser; output started in
            ...", analysez tout de suite d'où vient la fuite grâce au message d'erreur. Toute action
            entraînant un envoi d'en-têtes <acronym>HTTP</acronym>, comme envoyer un cookie, doit être effectuée avant
            d'envoyer du contenu standard (non bufferisé), sauf si le buffer de sortie de <acronym>PHP</acronym> est
            activé.
        </para>

        <itemizedlist mark="opencircle">
            <listitem>
                <para>
                    Utiliser <ulink url="http://php.net/outcontrol">le buffer de
                    sortie</ulink> résout souvent le problème, et peut améliorer les performances.
                    Par exemple, une valeur <code>php.ini</code>, "<code>output_buffering =
                    65535</code>" active un buffer de 64K. Même si le buffer de sortie peut
                    améliorer les performances lorsqu'il est bien configuré, se reposer sur lui
                    concernant les erreurs "headers already sent" n'est pas suffisant. En effet, sa
                    taille peut être dépassé entraînant son vidage, et le problème revient.
                </para>
            </listitem>

            <listitem>
                <para>
                    Aussi, il convient d'organiser l'application de manière à ce que les
                    envois d'en-tête se passent avant l'envoi de contenu.
                </para>
            </listitem>

            <listitem>
                <para>
                    Si Zend_Session produit ce message, cherchez la cause grâce au message
                    d'erreur indiquant d'où provient "la fuite". Aussi, des opérations comme
                    <methodname>destroy()</methodname> envoient des en-têtes concernant la destruction du cookie
                    de session. Si vous ne voulez pas ces informations envoyées, utilisez alors
                    <methodname>destroy(false)</methodname>.
                </para>
            </listitem>

            <listitem>
                <para>
                    Supprimez tous les balises de fermeture "<code>?&gt;</code>", si elles
                    terminent du code <acronym>PHP</acronym>. Elles sont facultatives et les nouvelles lignes blanches
                    éventuelles en fin de fichier ne seront pas envoyées, car parsées par
                    <acronym>PHP</acronym>.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.session.global_session_management.session_identifiers">
        <title>Identifiants de session</title>

        <para>
            Les bonnes pratiques d'utilisation des sessions avec Zend Framework passent par un
            cookie, plutôt que se reporter à l'URL concernant l'identifiant de session. Par défaut,
            le composant Zend_Session est bloqué sur l'utilisation unique du cookie comme moyen de
            propagation de l'identifiant de session. La session <acronym>PHP</acronym> va alors utiliser cet
            identifiant de manière à identifier de manière unique chaque client (navigateur) qui s'y
            connecte, et maintenir un état entre leurs transactions, donnant l'impression de
            conservation de données. Zend_Session_* utilise alors le tableau
            (<varname>$_SESSION</varname>) et vous y donne accès d'une manière objet élégante. Attention,
            si un attaquant arrive à accéder au cookie de session d'une victime, il pourra alors
            tromper le serveur, et se faire passer pour la victime. Ce comportement n'est pas unique
            à <acronym>PHP</acronym>, ni à Zend Framework, mais au Web en général, et au protocole <acronym>HTTP</acronym>. La méthode
            <methodname>regenerateId()</methodname> permet de changer l'identifiant de session stocké dans le
            cookie du client, par un autre, en théorie imprévisible. Notez que par la suite, nous
            confondons les termes 'client' et 'navigateur', même si ceci n'est pas tout à fait
            juste.
        </para>

        <para>
            Changer l'identifiant de session permet d'aider contre le vol de données. Si un
            attaquant possède l'identifiant d'une victime, le changer ne changera rien pour la
            victime, mais provoquera une invalidation de la session de l'attaquant, qui ne connaît
            alors pas la nouvelle valeur de l'identifiant de session. Non seulement
            <methodname>regenerateId()</methodname> change l'identifiant de session, mais en plus il migre les
            données de l'ancien identifiant vers le nouveau, invalidant totalement l'ancien.
        </para>

        <para>
            Quand régénérer cet identifiant ? En théorie, mettre
            <methodname>Zend_Session::regenerateId()</methodname> en bootstrap est la manière la plus
            adaptée pour sécuriser une session. Cependant, ceci a un coût non négligeable, car il
            faut alors à chaque fois régénérer un identifiant, et renvoyer un nouveau cookie au
            client. Il est alors nécessaire de déterminer les situations 'à risque', et régénérer
            alors l'identifiant de session dans de telles situations. Ces situations peuvent être
            par exemple l'authentification d'un client, ou encore son élévation de privilèges. Si
            vous appelez <methodname>rememberMe()</methodname>, n'appelez alors pas <methodname>regenerateId()</methodname>,
            car elle sera appelée de manière automatique.
        </para>

        <sect3 id="zend.session.global_session_management.session_identifiers.hijacking_and_fixation">
            <title>Vol de session et fixation</title>

            <para>
                Éviter <ulink url="http://en.wikipedia.org/wiki/Cross_site_scripting">les
                failles cross-site script (XSS) </ulink> aide à éviter le vol de session. Selon
                <ulink url="http://secunia.com/">Secunia</ulink>, les problèmes XSS sont fréquents,
                quelque soit le langage utilisé pour créer l'application Web. Plutôt que de se
                considérer invulnérable, considérez votre application de manière à minimiser
                l'impact d'une éventuelle faille XSS. Avec XSS, l'attaquant n'a pas besoin d'accéder
                au trafic de la victime, sur le réseau. Si la victime possède déjà un cookie de
                session, javascript peut permettre à l'attaquant de voler celui-ci, et donc la
                session. Dans le cas de victimes sans cookie, l'attaquant peut utiliser XSS pour
                créer un cookie avec un session id connu, et l'envoyer à la victime, fixant ainsi la
                session. L'attaquant peut dès lors visualiser toute la session de la victime au fur
                et à mesure que celle-ci surfe, sans se rendre compte de rien. Cependant,
                l'attaquant ne peut modifier l'état de la session du coté <acronym>PHP</acronym> ( la fermer par
                exemple ), sauf si l'application possède d'autres vulnérabilités (CSRF), ou si le
                <code>save_path</code> est modifiable.
            </para>

            <para>
                En elle-même, la fonction <methodname>Zend_Session::regenerateId()</methodname>
                utilisée à la première utilisation de la session, ne protège pas contre la fixation.
                Ceci peut paraître contradictoire, mais un attaquant peut très bien initialiser une
                session de lui-même, qui sera alors rafraîchie (régénérée), et dont il connaîtra
                alors l'identifiant. Il n'aura plus qu'à fixer cet identifiant dans un javascript
                pour qu'une victime l'utilise, et la faille est à nouveau présente. Aussi, fixer la
                session par l'URL est extrêmement simple, mais n'est possible que lorsque
                <code>use_only_cookies = off</code>.
            </para>

            <para>
                Le vol de session ne peut se remarqué que si vous arrivez à faire la
                différence entre l'attaquant et la victime. Ce n'est pas chose simple, et les
                techniques utilisées ne sont jamais fiables à 100%. L'IP peut être utilisée, même si
                celle-ci n'est pas totalement fiable. Les en-têtes du navigateur Web, eux, le sont
                déjà plus (lorsque 2 requêtes successives avec le même identifiant de session
                arrivent au serveur, si l'une prétend être issue de FireFox et l'autre d'Opéra,
                alors très probablement qu'il s'agit de 2 personnes différentes, mais ayant le même
                identifiant de session. Typiquement : l'attaquant et sa victime.) Il est très
                difficile de différencier l'attaquant et la victime, c'est d'ailleurs impossible
                dans la suite de cas suivants : <itemizedlist mark="opencircle">
                        <listitem>
                        <para>
                            l'attaquant initialise une session pour obtenir un identifiant
                            valide.
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            l'attaquant utilise une faille XSS pour envoyer un cookie de
                            session à une victime, possédant son propre identifiant de session
                            (fixation).
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            l'attaquant et la victime utilisent le même navigateur, sont
                            derrière le même proxy.
                        </para>
                    </listitem>
                </itemizedlist> Le code suivant permet d'empêcher l'attaquant de connaître
                l'identifiant de session de la victime (sauf s'il arrive à le fixer):
            </para>

            <example id="zend.session.global_session_management.session_identifiers.hijacking_and_fixation.example">
                <title>Vol et fixation, protections</title>

                <programlisting language="php"><![CDATA[
$defaultNamespace = new Zend_Session_Namespace();

if (!isset($defaultNamespace->initialized)) {
    Zend_Session::regenerateId();
    $defaultNamespace->initialized = true;
}
]]></programlisting>
            </example>
        </sect3>
    </sect2>

    <sect2 id="zend.session.global_session_management.rememberme">
        <title><methodname>rememberMe(integer $seconds)</methodname></title>

        <para>
            Par défaut, la session se termine lorsque le client ferme son navigateur. Il peut
            cependant être nécessaire de faire en sorte que même après la fermeture, le cookie de
            session persiste un certain temps dans le navigateur. Utilisez
            <methodname>Zend_Session::rememberMe()</methodname> avant tout démarrage de la session,
            afin de spécifier à celle-ci qu'elle devra utiliser un cookie persistant du coté du
            client. Ce cookie persistera alors $seconds secondes. Si vous ne précisez pas de temps,
            <code>remember_me_seconds</code>, sera utilisé. Cette valeur se paramètre d'ailleurs au
            moyen de <methodname>Zend_Session::setOptions()</methodname>.
        </para>
    </sect2>

    <sect2 id="zend.session.global_session_management.forgetme">
        <title><methodname>forgetMe()</methodname></title>

        <para>
            Cette fonction est analogue à <methodname>rememberMe()</methodname> sauf qu'elle demande au
            cookie de session du navigateur client d'être détruit à la fermeture de celui-ci (et non
            éventuellement après X temps).
        </para>
    </sect2>

    <sect2 id="zend.session.global_session_management.sessionexists">
        <title><methodname>sessionExists()</methodname></title>

        <para>
            Utilisez cette méthode afin de savoir si une session existe pour le client (la
            requête) actuel. Ceci doit être utilisé avant le démarrage de la session.
        </para>
    </sect2>

    <sect2 id="zend.session.global_session_management.destroy">
        <title><methodname>destroy(bool $remove_cookie = true, bool $readonly = true)</methodname></title>

        <para>
            <methodname>Zend_Session::destroy()</methodname> détruit la session et toutes les
            données la concernant. Cependant, aucune variable dans <acronym>PHP</acronym> n'est affectée, donc vos
            namespaces de session (instances de <classname>Zend_Session_Namespace</classname>)
            restent lisibles. Pour compléter la "déconnexion", laissez le premier paramètre à
            <constant>TRUE</constant> (par défaut), demandant l'expiration du cookie de session du client.
            <varname>$readonly</varname> permet d'empêcher la future création de namespaces (new
            <classname>Zend_Session_Namespace</classname>) ou des opérations d'écriture via
            <classname>Zend_Session</classname>.
        </para>

        <para>
            Si vous voyez le message d'erreur "Cannot modify header information - headers
            already sent", alors tentez de ne pas utiliser <constant>TRUE</constant> comme valeur du premier
            argument (ceci demande l'expiration du cookie de session, ou voyez <link
                linkend="zend.session.global_session_management.headers_sent">cette section</link>. Ainsi,
            <methodname>Zend_Session::destroy(true)</methodname> doit être appelé avant tout envoi
            d'en-tête <acronym>HTTP</acronym> par <acronym>PHP</acronym>, ou alors la bufferisation de sortie doit être activée (sans que
            celui-ci ne déborde).
        </para>

        <note>
            <title>Exception</title>

            <para>
                Par défaut, <varname>$readonly</varname> est activé et toute opération future
                d'écriture dans la session lèvera une exception.
            </para>
        </note>
    </sect2>

    <sect2 id="zend.session.global_session_management.stop">
        <title><methodname>stop()</methodname></title>

        <para>
            Cette méthode ne fait rien d'autre que de verrouiller la session en écriture. Tout
            appel futur d'écriture via des instances de
            <classname>Zend_Session_Namespace</classname> ou <classname>Zend_Session</classname>
            lèvera une exception.
        </para>
    </sect2>

    <sect2 id="zend.session.global_session_management.writeclose">
        <title><methodname>writeClose($readonly = true)</methodname></title>

        <para>
            Ferme la session coté serveur, soit enregistre les variables de session dans le
            support, et détache <varname>$_SESSION</varname> de son support de stockage. Le paramètre
            optionnel <varname>$readonly</varname> empêche alors toute future écriture via
            <classname>Zend_Session</classname> ou <classname>Zend_Session_Namespace</classname>.
            Ces écritures lèveront une exception.
        </para>

        <note>
            <title>Exception</title>

            <para>
                Par défaut, <varname>$readonly</varname> est activé, et donc tout appel d'écriture
                futur dans la session générera une exception. Certaines applications peuvent
                nécessiter de conserver un accès en écriture dans <varname>$_SESSION</varname>, même si ce
                tableau a été déconnecté de son support de stockage avec
                <methodname>session_write_close()</methodname>. Ainsi, Zend Framework propose cette option en
                passant à <constant>FALSE</constant> la valeur de <varname>$readonly</varname>, mais ce n'est pas
                une pratique conseillée.
            </para>
        </note>
    </sect2>

    <sect2 id="zend.session.global_session_management.expiresessioncookie">
        <title><methodname>expireSessionCookie()</methodname></title>

        <para>
            Cette méthode envoie un cookie d'identifiant de session périmé au client. Quelque
            fois cette technique est utilisée pour déconnecter le client de sa session.
        </para>
    </sect2>

    <sect2 id="zend.session.global_session_management.savehandler">
        <title><code>setSaveHandler(Zend_Session_SaveHandler_Interface
        $interface)</code></title>

        <para>
            Cette méthode propose une correspondance orientée objet de <ulink
            url="http://php.net/session_set_save_handler"><methodname>session_set_save_handler()</methodname></ulink>.
        </para>
    </sect2>

    <sect2 id="zend.session.global_session_management.namespaceisset">
        <title><methodname>namespaceIsset($namespace)</methodname></title>

        <para>Cette méthode permet de déterminer si un namespace existe dans la session.</para>

        <note>
            <title>Exception</title>

            <para>
                Une exception sera levée si la session n'est pas lisible (n'a pas été
                démarrée).
            </para>
        </note>
    </sect2>

    <sect2 id="zend.session.global_session_management.namespaceunset">
        <title><methodname>namespaceUnset($namespace)</methodname></title>

        <para>
            Utilisez <methodname>Zend_Session::namespaceUnset($namespace)</methodname> pour
            détruire un namespace entier de la session. Comme pour les tableaux <acronym>PHP</acronym>, si le tableau
            est détruit, les objets à l'intérieur ne le sont pas s'il reste des références vers eux
            dans d'autres tableaux ou objets toujours accessibles. Ainsi
            <methodname>namespaceUnset()</methodname> ne détruit pas "en profondeur" la variable de session
            associée au namespace. Voyez <ulink url="http://php.net/references">les références en
            <acronym>PHP</acronym></ulink> pour plus d'infos.
        </para>

        <note>
            <title>Exception</title>

            <para>
                Une exception sera envoyée si le namespace n'est pas écrivable (après un appel
                à <methodname>destroy()</methodname>).
            </para>
        </note>
    </sect2>

    <sect2 id="zend.session.global_session_management.namespaceget">
        <title><methodname>namespaceGet($namespace)</methodname></title>

        <para>
            Déprécié: Utilisez <methodname>getIterator()</methodname> dans
            <classname>Zend_Session_Namespace</classname>. Cette méthode retourne un tableau du
            contenu du namespace $namespace. Si vous avez une raison de conserver cette méthode,
            faites nous part de vos remarques à <ulink
            url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>.
        </para>

        <note>
            <title>Exception</title>

            <para>
                Une exception sera levée si la session n'est pas lisible (n'a pas été
                démarrée).
            </para>
        </note>
    </sect2>

    <sect2 id="zend.session.global_session_management.getiterator">
        <title><methodname>getIterator()</methodname></title>

        <para>
            <methodname>getIterator()</methodname> retourne un <code>ArrayObject</code> contenant tous les
            noms des namespaces de session.
        </para>

        <note>
            <title>Exception</title>

            <para>
                Une exception sera levée si la session n'est pas lisible (n'a pas été
                démarrée).
            </para>
        </note>
    </sect2>
</sect1>