Exercice 1 : Forum - Le projet Back-end   

Créez un répertoire forum-angular-php. À l’intérieur, créez à l’aide de votre IDE un projet PHP pour le back-end de votre forum. Je suggérerais de lui donner un nom explicite, comme backend.

Les variables super globales en PHP

Définition

Une variable superglobale est une variable accessible dans tous les scopes.

Elles sont prédéfinies dans PHP et portent des noms en majuscules.

Ce sont des tableaux (par exemple, $GLOBALS['x'] permet d’accéder à $x).

Les variables superglobales qui vous seront le plus utiles sont :

Ces variables sont directement accessibles à l’intérieur des fonctions. Pas besoin de les déclarer en global pour cela.

Celles qui vous seront particulièrement utiles pour votre forum seront $_POST et/ou $_REQUEST, $_SERVER et $_SESSION.

Si vous avez besoin de plus d’informations sur ces variables, reportez-vous à la documentation de PHP :

https://www.php.net/manual/en/reserved.variables.php

Interactions entre le client et le serveur

Récupérer les informations transmises par le client  

Comme indiqué précédemment, les variables superglobales $_POST, $_GET et $_REQUEST vous permettent de récupérer les informations transmises par le client au serveur. Démonstration : considérons le formulaire HTML ci-dessous. Il contient un input et un bouton « submit ». Quand on clique sur ce dernier, on transmet les informations de la page au serveur, plus précisément au script PHP form.php (cf. la ligne 4).

form.html
1<!doctype html>
2<html>
3<body>
4  <form method="post" action="form.php" id="act">
5    <input type="text" name="texte" width="30" />
6    <input type="submit" name="xsub" value="bouton">
7  </form>
8</body>
9</html>

Le script PHP form.php que nous allons utiliser est le suivant :

form.php
<?php

echo "<pre>\n";
print_r ($_REQUEST);
echo "</pre>\n";

?>

Si on a saisi la chaîne « sss » dans l’input, form.php renverra la « page » HTML suivante : 

<pre>
Array
(
    [texte] = sss
    [xsub] = bouton
)
</pre>

On voit ainsi que $_REQUEST['texte'] contient la valeur de l’input du formulaire, celui dont la propriété name était précisément texte. C’est ainsi que l’on peut récupérer dans un script PHP les informations transmises par le client. Notez, ici, que le formulaire indique quelle méthode il va utiliser pour transmettre ses données : method="post". Cela signifie que toutes les données vont être transmises au $_POST du script PHP (et donc, a fortiori, au $_REQUEST).

Transmettre des informations en JSON plutôt qu'en HTML  

PHP possède une fonction header qui permet de modifier la manière dont sont transmises les informations. Cela permet, notamment, d’indiquer que l’on va envoyer des données au format JSON, mais également de résoudre un problème que vous allez rencontrer : le CORS (Cross Origin Resource Sharing), mais je spoile, je spoile…

json.php
<?php
// avec ce header on indique que nos affichages sont au format json
header('Content-type:application/json;charset=utf8');

// on utilise la fonction json_encode pour transformer des objets PHP en JSON
echo json_encode([
    'cle1' => 'xxx',
    'cle2' => 'yyy'
]);

Exercice 2 : v'là le postier   

Installez l’application postman via l’url :

https://www.postman.com

Attention : vous n’avez pas besoin de vous créer un compte. Cliquez directement sur « Download the Desktop app ».

Postman est très pratique pour tester des backends, notamment ceux en PHP. Il vous permet en effet :

  1. de charger des pages web, comme le ferait un navigateur,

  2. de transmettre des informations au serveur web comme si on avait rempli un formulaire,

  3. d’utiliser des cookies, notamment ceux de session.

Par exemple, si l’on teste le code json.php ci-dessus avec postman, on obtient quelque chose ressemblant à l’image ci-dessous :

Postman interrogeant json.php sur notre serveur web

Copiez-collez le fichier json.php sur votre serveur web et utilisez postman (sans créer de compte) pour y accéder (ici, il faudra indiquer l’url sur le serveur permettant d’accéder au script et ne pas oublier de démarrer le serveur web).

Exercice 3 : Le retour du postier   

Réalisez un POST sur l’url :

https://pageperso.lis-lab.fr/christophe.gonzales/teaching/mobile/ressources/fr-FR/checkLogin.php

qui simule le back-end du forum de démonstration, cf. l’image ci-dessous. Si vous transmettez dans le body de la requête un form-data avec des champs login et password ayant les valeurs correspondantes au login/password des utilisateurs du site (cf. AMeTICE), vous obtiendrez un message vous indiquant que votre authentification a été réussie. form-data est le format utilisé lorsque vous remplissez un formulaire HTML <form></form>.

Utilisation de postman avec le forum de démonstration

L'authentification par session

Problème : comment s’assurer que, lorsqu’un client demande l’exécution d’un script sur le backend, il a bien les droits de le faire et, le cas échéant, si le script dépend de l’identité du client, comment connaître celle-ci.

Exemple : sur le forum que vous allez programmer, un utilisateur ne peut récupérer la liste des cours que s’il s’est authentifié au préalable. Par ailleurs, ce sont uniquement les cours qu’il suit qui doivent être transmis au frontend, donc on doit savoir qui est l’utilisateur. Évidemment, dans chacune de ses requêtes, le frontend pourrait transmettre en POST l’identité de l’utilisateur mais cette option n’est pas satisfaisante car n’importe qui pourrait alors usurper l’identité de n’importe quel utilisateur. Il faut donc que ce dernier s’authentifie et que le backend conserve cette authentification. Les sessions sont l’outil par excellence en PHP pour réaliser cela.

En effet, les sessions permettent de stocker sur le serveur des informations concernant le client. Pour cela, PHP propose une fonction session_start() qui permet de démarrer une nouvelle session ou bien de reprendre une session existante. Lorsque l’on est dans une session, les données du tableau superglobal $_SESSION sont sauvegardées dans un fichier sur le serveur. Lorsque ce dernier envoie au client la page à afficher, il transmet également un cookie appelé PHPSESSID spécifiant dans quel fichier les données ont été sauvegardées. Lorsque le client recontacte à nouveau le serveur pour accéder à une autre URL, il lui transmet ce cookie et le serveur peut donc recharger dans $_SESSION le contenu du fichier. Ainsi, on retrouve dans $_SESSION les informations qu’on y avait placées lors d’un accès précédent au serveur. Si le client ne transmet pas le cookie PHPSESSID ou bien si celui-ci est trop vieux, la fonction session_start() crée une nouvelle session (un nouveau fichier). Prenons un exemple pour illustrer tout cela. Dans le forum, l’utilisateur s’authentifie. Le client accède donc une première fois à une URL checkLogin.php vérifiant le login/password de l’utilisateur. Supposons qu’ils sont corrects. Le serveur sauvegarde alors dans une session les informations sur l’utilisateur puis il envoie un message au frontend en lui disant que tout est ok et il passe dans ce message le cookie PHPSESSID. Le frontend demande alors la liste des cours de l’utilisateur au serveur (URL getCourses.php), en lui passant le cookie. En exploitant ce dernier, le serveur recharge les informations de l’utilisateur et peut répondre au frontend, tout en lui renvoyant à nouveau le cookie. Tant que le cookie est échangé entre le client et le serveur, dans les deux sens, la session reste active.

Exercice 4 : Forum - Authentification - partie 1   

Écrivez un script PHP auth.php qui démarre une nouvelle session ou en restaure une ancienne via l’instruction session_start() ou, éventuellement, session_start([“cookie_samesite” => “Lax”]) si votre navigateur vous embête encore avec le CORS, cf. :

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Dans ce script, affichez le contenu du tableau $_SESSION via la fonction PHP print_r(), puis, en dessous, rajoutez un élément dont la clef est test et la valeur la chaîne « test des sessions ». Avec postman, accédez une première fois via un POST à auth.php. Vous devriez voir en bas de la fenêtre de postman, dans le body, un tableau vide. Vous devriez également voir dans la rubrique Cookies, un cookie dont le nom est PHPSESSID. C’est votre cookie de session.

Dans postman, recliquez sur le bouton Send afin de réaccéder à votre script auth.php. Maintenant, dans le body, vous devriez voir ce que vous aviez ajouté dans la variable $_SESSION.

Les variables de session sont stockées par défaut une trentaine de minutes sur votre serveur. Pendant cette demi-heure, si vous vous reconnectez, vos scripts PHP retrouvent toutes les informations stockées dans $_SESSION. Pour votre forum, l’idée consistera à sauvegarder les informations concernant l’utilisateur qui seront pertinentes pour les requêtes ultérieures effectuées par le frontend.

Exercice 5 : Forum - Authentification - partie 2   

Supprimez du fichier auth.php toutes les instructions que vous avez écrites excepté le session_start(). Maintenant, écrivez deux fonctions~:

  1. une fonction authenticate() qui:

    1. vérifie que la variable $_POST contient des champs login et password (cf. les fonctions array_key_exists et isset de PHP :

      https://www.php.net/manual/fr/funcref.php,

      sous-sections concernant les « tableaux » et « Extensions relatives aux variables »).

    2. Si les champs existent, vérifiez que ce couple (login, password) est correct. Vous pouvez pour cela sauvegarder dans des variables globales en début de fichier un login et un password corrects et les comparer au contenu de $_POST. Vous changerez cela plus tard quand vous pourrez vous connecter à votre base de données mySQL.

    3. Si le login/password est correct, votre fonction doit placer dans la variable $_SESSION des informations permettant d’identifier l’utilisateur lors de ses connexions futures, puis elle retourne la valeur true pour indiquer que l’identification s’est bien passée.

      En revanche, s’il manque dans le $_POST le login et/ou le password, ou bien si votre base de données ne les contient pas, la fonction ne modifie pas $_SESSION et retourne la valeur false.

  2. une fonction isAuthenticated() qui renvoie true si les clefs des informations que vous avez ajoutées à $_SESSION en cas d’authentification réussie existent bien, et renvoie false sinon.

L’idée de ces deux fonctions est la suivante : dans le script checkLogin.php qui réalisera l’authentification de l’utilisateur, on utilisera authenticate() afin de s’assurer que l’utilisateur existe bien. Dans tous les autres scripts (getCourses.php, etc.), on utilisera isAuthenticated() afin de vérifier que l’utilisateur s’est déjà authentifié.

Testez vos fonctions via postman. Évidemment, il va falloir faire des affichages pour vérifier que tout fonctionne bien. Pour cela, il vous suffit simplement de rajouter en bas de votre fichier PHP un appel à la fonction authenticate() ou bien à isAuthenticated() et d’afficher un message en fonction de la valeur retournée. Quand vos tests sont OK, supprimez ces appels.

Exercice 6 : Forum - Helper   

Téléchargez le script helper.php sur l’URL :

https://pageperso.lis-lab.fr/christophe.gonzales/teaching/mobile/ressources/fr-FR/helper.php

et placez-le dans le répertoire backend de votre forum. Ce script contient :

  1. des instructions qui modifient les headers des pages que retournera votre backend afin de contourner la restriction de sécurité appelée CORS (cross-origin resource sharing), cf.

    https://developer.mozilla.org/fr/docs/Web/HTTP/CORS

    En effet, dans vos TPs, vous allez tester votre frontend Angular sur le port 4200 de votre machine et votre serveur Apache est, lui, sur le port 80. Par conséquent, vous utilisez deux serveurs différents et cela induit le CORS, qui empêche à Apache et Angular de converser entre eux. Les headers de helper.php suppriment cette restriction.

  2. deux fonctions sendMessage et sendError qui simplifient et homogénéisent le transfert de données vers Angular. Quand on transfère des informations à Angular, on le fait en principe en utilisant le format JSON. Ces fonctions créent le format en question. Quand vous souhaitez renvoyer un message d’erreur à Angular, il suffit d’appeler sendError en lui passant en paramètre une chaîne de caractères précisant l’erreur qui s’est produite. Si tout s’est bien passé, en revanche, utilisez sendMessage en lui passant en paramètre les données que vous souhaitez renvoyer à Angular. Notez que la dernière instruction de ces fonctions est die. Cela permet de stopper le script PHP: après un die, aucune autre instruction PHP n’est exécutée.

  3. des instructions qui utilisent les fonctions que vous avez écrites dans l’exercice précédent : on y précise que si le script PHP auquel l’utilisateur essaye d’accéder ne s’appelle pas checkLogin.php et si l’utilisateur n’est pas authentifié, on renvoie un message d’erreur JSON et on stoppe l’exécution de PHP (die), sinon on ne fait rien. Par conséquent, si vous incluez helper.php en début de tous vos scripts (cf. require_once), ceux-ci exécuteront leur code si et seulement si l’utilisateur est bien authentifié.

Exercice 7 : Forum - checkLogin.php   

Créez un script checkLogin.php que l’on contactera via un POST. Ce script PHP vérifiera que les champs login et password du POST correspondent bien à un utilisateur référencé dans votre base de données. Le cas échéant, il renverra un message JSON contenant une chaîne vide. Sinon, il renverra un message d’erreur JSON précisant que le login/password est invalide. Évidemment, pour cela, vous vous appuierez sur les fonctions des fichiers helper.php et auth.php.

Testez votre script checkLogin.php via postman.

 
© C.G. 2007 - 2025