Skip to content

6. Portées des données

Une application web sert de nombreux utilisateurs à la fois, et chacun d'eux enchaîne de nombreuses requêtes. Une donnée peut donc être partagée à plusieurs niveaux, qu'on appelle sa portée :

  • la portée application : la donnée est partagée par tous les utilisateurs, pendant toute la vie de l'application (la liste des médecins, par exemple) ;
  • la portée requête : la donnée n'existe que le temps de traiter une requête (le modèle d'une vue, l'utilisateur connecté tel qu'il a été reconnu pour cette requête) ;
  • la portée session : la donnée est propre à un utilisateur, et doit survivre d'une requête à la suivante (la langue choisie, un panier) ;
  • la portée client : une donnée confiée au navigateur lui-même, dans un cookie.

En [PHP], ces portées prennent un tour particulier, parce que l'application est reconstruite à chaque requête (exemple 01) : rien ne survit en mémoire d'une requête à la suivante. Toute donnée qui doit durer plus longtemps qu'une requête est donc rangée hors de [PHP] : dans le cache, une base de données, des fichiers, ou chez le client. C'est la conception dite « sans partage » (*shared nothing*) : chaque requête est traitée isolément, par un processus qui ne partage rien avec ceux qui traitent les autres. Elle a de grands avantages : une erreur n'affecte qu'une requête, aucune donnée ne fuit d'un utilisateur à l'autre, et l'on peut faire tourner plusieurs serveurs identiques derrière un répartiteur de charge, pourvu qu'ils partagent le même cache et la même base.

En [Laravel], chaque portée a son support :

Portée
Support
Durée de vie
application
le cache (façade [Cache], exemple 20), ou la base de données
la durée choisie, ou sans limite
requête
les objets du conteneur (un singleton ne vit qu'une requête), les attributs de la requête (exemple 12)
le traitement d'une requête
session
la session ([$request->session()], [session()]), gardée par le serveur, retrouvée grâce à un cookie
2 heures d'inactivité par défaut ([SESSION_LIFETIME])
client
un cookie ([withCookie], exemple 22), chiffré par défaut
la durée donnée au cookie

La session de [Laravel] est une session tenue par le serveur, comme celles de [Java] ([JSESSIONID]) ou du [PHP] classique ([PHPSESSID]) : ses données sont rangées sur le serveur (un fichier par session, avec la configuration de nos exemples), et le navigateur n'en détient que l'identifiant, dans un cookie chiffré (exemple 20). C'est une différence avec [Flask], dont la session est rangée tout entière dans un cookie signé, chez le client.

6.1. Exemple 23 : les portées

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
23-portees/
├── app/
│   ├── Http/
│   │   └── Controllers/
│   │       └── PorteesController.php
│   └── Services/
│       ├── CompteurService.php
│       └── RequeteInfos.php
├── resources/
│   └── views/
│       └── portees/
│           └── portees.blade.php
└── ...

6.1.1. Les objets : app/Services/CompteurService.php et RequeteInfos.php

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?php
// app/Services/CompteurService.php : portée APPLICATION, un compteur partagé par
// toutes les requêtes de tous les utilisateurs, rangé dans le cache (cf. exemple 20)

namespace App\Services;

use Illuminate\Support\Facades\Cache;

class CompteurService
{
    // un numéro de plus sous la clé [$cle] ; le cache "fichier" n'augmente pas un
    // nombre de façon atomique : un verrou protège la lecture et l'écriture
    public static function suivant(string $cle): int
    {
        return Cache::lock("$cle-verrou", 10)->block(5, function () use ($cle) {
            $valeur = Cache::get($cle, 0) + 1;
            Cache::forever($cle, $valeur);
            return $valeur;
        });
    }

    public function incrementer(): int
    {
        return self::suivant('visites');
    }
}
  • lignes 13-20 : un compteur de portée application : un nombre rangé dans le cache, sous une clé, et augmenté de 1 à chaque appel. Le cache propose une méthode [Cache::increment], mais, avec le magasin « fichier » de nos exemples, elle n'est pas atomique : elle lit la valeur, l'augmente, puis l'écrit, et deux requêtes simultanées pourraient lire la même valeur : une visite serait perdue. Un verrou (exemple 20) protège donc la lecture et l'écriture. (Avec un magasin comme [Redis] ou une base de données, [Cache::increment] est atomique, et le verrou inutile.) La fonction rend la valeur du verrou, qui est celle que rend la fonction qu'il protège ;
  • lignes 22-25 : le compteur des visites.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
<?php
// app/Services/RequeteInfos.php : portée REQUÊTE, les informations d'une requête

namespace App\Services;

class RequeteInfos
{
    public readonly int $numero;

    public readonly string $debut;

    public function __construct()
    {
        // un numéro par OBJET créé, tiré d'un compteur commun à toutes les requêtes
        $this->numero = CompteurService::suivant('instances');
        // l'heure, avec ses millisecondes (v)
        $this->debut = now()->format('H:i:s.v');
    }
}
  • lignes 8-10 : des propriétés déclarées [readonly] une à une (et non la classe entière) : elles ne peuvent être affectées qu'une fois, par le constructeur ;
  • lignes 12-18 : des informations de portée requête : un numéro, tiré d'un compteur commun à toutes les requêtes (le compteur de la classe précédente, sous une autre clé), et l'heure de la requête. La fonction [now()] rend l'instant présent, une date [Carbon] ; le format [v] écrit les millisecondes.

6.1.2. La configuration : bootstrap/app.php

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?php
// bootstrap/app.php : l'application de l'exemple 23

use App\Services\CompteurService;
use App\Services\RequeteInfos;
use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Middleware;

(require __DIR__.'/../../vendor/autoload.php')->addPsr4('App\\', __DIR__.'/../app/');

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        // la route qui sert Bootstrap (cf. exemple 15)
        then: fn () => require __DIR__.'/../../commun/bootstrap.php')
    ->withMiddleware(function (Middleware $middleware): void {
        // le cookie [mesVisites] n'est pas chiffré (les autres le sont)
        $middleware->encryptCookies(except: ['mesVisites']);
    })
    ->withExceptions()
    // un seul objet de chaque classe pendant le traitement d'une requête
    ->withSingletons([CompteurService::class])
    ->withScopedSingletons([RequeteInfos::class])
    ->create();
  • ligne 18 : le cookie [mesVisites] n'est pas chiffré ; tous les autres le sont (exemple 22) ;
  • lignes 22-23 : les deux services sont déclarés au conteneur. [withSingletons] (exemple 06) : un seul objet, créé à la première demande. [withScopedSingletons] : un seul objet par requête. En [PHP] ordinaire, les deux reviennent au même, puisque chaque requête reconstruit l'application et son conteneur. La différence apparaît avec [Laravel Octane], un serveur d'applications qui garde l'application en mémoire d'une requête à l'autre, pour aller plus vite : un singleton y est partagé par toutes les requêtes, un singleton « scopé » est recréé pour chacune. Déclarer la portée voulue rend le code correct dans les deux cas.

6.1.3. Le contrôleur : app/Http/Controllers/PorteesController.php

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<?php
// app/Http/Controllers/PorteesController.php : les quatre portées des données

namespace App\Http\Controllers;

use App\Services\CompteurService;
use App\Services\RequeteInfos;
use Illuminate\Http\Request;
use Illuminate\Http\Response;

class PorteesController
{
    // les deux objets sont fournis par le conteneur (cf. bootstrap/app.php)
    public function afficher(Request $request, CompteurService $compteur, RequeteInfos $infos): Response
    {
        // APPLICATION : le compteur partagé
        $total = $compteur->incrementer();
        // SESSION : des données propres à CE navigateur, gardées par le SERVEUR
        // (un fichier de storage/framework/sessions), retrouvées grâce au cookie de session
        $visitesSession = $request->session()->increment('visites');
        // CLIENT : des données conservées par le NAVIGATEUR dans des cookies,
        // renvoyées au serveur à chaque requête ; l'un en clair, l'autre chiffré
        $mesVisites = (int) $request->cookie('mesVisites') + 1;
        $mesVisitesChiffre = (int) $request->cookie('mesVisitesChiffre') + 1;
        return response()->view('portees.portees', [
            'total' => $total, 'instance' => $infos->numero,
            'visitesSession' => $visitesSession, 'mesVisites' => $mesVisites,
            'mesVisitesChiffre' => $mesVisitesChiffre,
        ])->withCookie(cookie('mesVisites', $mesVisites))
            ->withCookie(cookie('mesVisitesChiffre', $mesVisitesChiffre));
    }
}
  • ligne 14 : l'action reçoit la requête et les deux services, fournis par le conteneur ;
  • ligne 17 : la portée application ;
  • ligne 20 : la portée session. [$request->session()] rend la session de l'utilisateur ; sa méthode [increment] augmente de 1 la valeur d'une clé (0 si elle est absente), et rend la nouvelle valeur. On lit une valeur par [get('visites')], on l'écrit par [put('visites', 3)] ; la fonction [session('visites')] est un raccourci pour la lecture. [Laravel] enregistre la session à la fin de la requête (le middleware [StartSession] du groupe [web]) ;
  • lignes 23-24 : la portée client, avec deux cookies. Leurs valeurs sont des chaînes, fournies par le navigateur, et donc peut-être absentes ou invalides : la conversion [(int)] rend 0 pour [null] ou pour un texte qui n'est pas un nombre ;
  • lignes 25-30 : pour déposer un cookie, il faut l'objet réponse : [response()->view(...)] le construit à partir de la vue (exemple 13), puis [withCookie] lui ajoute les cookies. Sans durée, un cookie dure jusqu'à la fermeture du navigateur (c'est un cookie « de session », au sens des navigateurs).

6.1.4. La vue : resources/views/portees/portees.blade.php

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<!doctype html>
<html lang="fr">
<head>
  <meta charset="utf-8">
  <title>Portées</title>
  <link rel="stylesheet" href="{{ route('bootstrap', 'css/bootstrap.min.css') }}">
</head>
<body>
  <div class="container py-3">
    <h1 class="h3">Les portées des données</h1>
    {{-- @inject : un objet demandé au conteneur, depuis la vue ; pendant la MÊME
         requête, c'est le même objet que celui de l'action --}}
    @inject('infos', 'App\Services\RequeteInfos')
    <ul>
      <li>application : {{ $total }} visite(s) du site, tous navigateurs confondus</li>
      <li>requête : objet n° {{ $instance }} (n° {{ $infos->numero }} dans la vue),
        requête reçue à {{ $infos->debut }}</li>
      <li>session : {{ $visitesSession }} visite(s) de ce navigateur ({{ session('visites') }} dans la vue)</li>
      <li>client : {{ $mesVisites }} visite(s) de ce navigateur (cookie en clair),
        {{ $mesVisitesChiffre }} (cookie chiffré)</li>
    </ul>
  </div>
</body>
</html>
  • ligne 13 : la directive [@inject] demande un objet au conteneur, depuis la vue, et le range dans une variable (ici [$infos]). Pendant une même requête, c'est le même objet [RequeteInfos] que celui de l'action : la vue affiche son numéro, qui doit être celui reçu de l'action ;
  • ligne 18 : la session est aussi accessible dans les vues.

6.1.5. Exécution

Après quelques visites, dans un navigateur :

Image

Suivons les requêtes avec [curl], qui joue le rôle d'un premier navigateur en conservant ses cookies dans le fichier [a.txt] :

1
curl -i -c a.txt -b a.txt http://localhost:8000/

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
HTTP/1.1 200 OK
Set-Cookie: mesVisites=1; path=/; httponly; samesite=lax
Set-Cookie: mesVisitesChiffre=eyJpdiI6IlNYLzF1MnBiUS82L2NjenE4K01RQnc9PSIsInZhbHVlIjoiejRQTC94clIy...; path=/; httponly; samesite=lax
Set-Cookie: XSRF-TOKEN=eyJpdiI6IlVCeGJtSTU4SVV2aTFvS1Ryb3A2SlE9PSIsInZhbHVlIjoicWM4RGQ1ZXNi...; expires=...; Max-Age=7200; path=/; samesite=lax
Set-Cookie: exemple23_session=eyJpdiI6IngrbWJBelphY3oyUDlYZkpFV1pKeVE9PSIsInZhbHVlIjoiRklyYWlN...; expires=...; Max-Age=7200; path=/; httponly; samesite=lax
...
      <li>application : 1 visite(s) du site, tous navigateurs confondus</li>
      <li>requête : objet n° 1 (n° 1 dans la vue),
        requête reçue à 16:19:05.709</li>
      <li>session : 1 visite(s) de ce navigateur (1 dans la vue)</li>
      <li>client : 1 visite(s) de ce navigateur (cookie en clair),
        1 (cookie chiffré)</li>
...

La réponse dépose quatre cookies. Le premier, [mesVisites], contient la valeur en clair. Le second, [mesVisitesChiffre], contient la même valeur, chiffrée : la partie visible est un document JSON codé en base 64, qui contient le vecteur d'initialisation du chiffrement ([iv]), la valeur chiffrée ([value]) et un code d'authentification ([mac]), qui garantit que la valeur n'a pas été modifiée. Les deux derniers sont ceux de la session et de la protection anti-CSRF (exemple 20). Une seconde visite, avec les mêmes cookies :

1
curl -i -c a.txt -b a.txt http://localhost:8000/

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
...
Set-Cookie: mesVisites=2; path=/; httponly; samesite=lax
...
      <li>application : 2 visite(s) du site, tous navigateurs confondus</li>
      <li>requête : objet n° 2 (n° 2 dans la vue),
        requête reçue à 16:19:05.731</li>
      <li>session : 2 visite(s) de ce navigateur (2 dans la vue)</li>
      <li>client : 2 visite(s) de ce navigateur (cookie en clair),
        2 (cookie chiffré)</li>
...

Un second « navigateur », avec son propre fichier de cookies, vide au départ :

1
curl -c b.txt -b b.txt http://localhost:8000/

1
2
3
4
5
6
      <li>application : 3 visite(s) du site, tous navigateurs confondus</li>
      <li>requête : objet n° 3 (n° 3 dans la vue),
        requête reçue à 16:19:05.747</li>
      <li>session : 1 visite(s) de ce navigateur (1 dans la vue)</li>
      <li>client : 1 visite(s) de ce navigateur (cookie en clair),
        1 (cookie chiffré)</li>

Le compteur de l'application a continué ; la session et les cookies du second navigateur repartent de 1. Chaque requête a eu son propre objet [RequeteInfos], et, dans chacune, l'action et la vue ont vu le même. Enfin, un utilisateur malhonnête fabrique ses cookies : 1000 visites dans [mesVisites], 999 dans [mesVisitesChiffre], et un identifiant de session de son invention :

1
curl -b "mesVisites=1000;mesVisitesChiffre=999;exemple23_session=abc" http://localhost:8000/

1
2
3
4
5
      <li>application : 4 visite(s) du site, tous navigateurs confondus</li>
      ...
      <li>session : 1 visite(s) de ce navigateur (1 dans la vue)</li>
      <li>client : 1001 visite(s) de ce navigateur (cookie en clair),
        1 (cookie chiffré)</li>

Le cookie en clair a été accepté tel quel : 1001 visites. Le cookie [mesVisitesChiffre], lui, n'a pas pu être déchiffré : [Laravel] l'a ignoré, comme s'il était absent. Il en va de même du cookie de session : l'utilisateur ne peut pas choisir la session d'un autre, et reçoit une session neuve. C'est toute la différence entre un cookie ordinaire et un cookie chiffré. Retenons-en la règle : une donnée venue du client n'est digne de confiance que si elle est protégée par le serveur (chiffrée, comme ici, ou signée, comme le jeton du chapitre sur l'authentification) ; les données qui n'ont rien à cacher, et dont le serveur vérifie la valeur (la langue de l'exemple 22), peuvent rester en clair.

https://stahe.github.io
Ce tutoriel, rédigé par l’IA d’Anthropic Claude à la demande de Serge Tahé, est mis à la disposition du public selon les termes de la licence Creative Commons Attribution – Pas d’utilisation commerciale – ShareAlike 3.0 Unported.