Maxime Puys
3 months ago
parent
83102a6ffd
commit
ea878d888f
@ -1,4 +1,4 @@
|
||||
# TP3: Base de données avec Doctrine
|
||||
# TP3.1: Base de données avec Doctrine
|
||||
|
||||
> This work is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/).
|
||||
> Permission is explicitly granted to copy, distribute and/or modify this document for educational purposes under the terms of the CC BY-NC-SA license.
|
||||
@ -0,0 +1,88 @@
|
||||
# TP3.2: Templating avec Twig
|
||||
|
||||
> This work is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/).
|
||||
> Permission is explicitly granted to copy, distribute and/or modify this document for educational purposes under the terms of the CC BY-NC-SA license.
|
||||
|
||||
## Objectifs
|
||||
|
||||
Les objectifs de ce TP sont :
|
||||
|
||||
- Comprendre et mettre en œuvre les opérations CRUD (Create, Read, Update,
|
||||
Delete) avec Twig dans une application Symfony.
|
||||
- S'approprier les structures de contrôle de Twig (`if`/`for`/etc).
|
||||
- Comprendre les méchanismes d'héritage et d'extension de templates.
|
||||
|
||||
## Consignes
|
||||
|
||||
- Durée : 2 heures
|
||||
- Tous vos projets `Symfony` sont à placer votre dossier `~/public_html`.
|
||||
- Utilisez le serveur `londres.uca.local` pour tester vos pages et non la
|
||||
commande `symfony server:start`.
|
||||
- Nous allons continuer notre réseau social nommé `TweetTok` où les messages
|
||||
sont nommés des `Twok`.
|
||||
- Lors du précédent TP, nous avons stocké les `Twoks` en BDD, mais avec un CRUD
|
||||
très rudimentaire.
|
||||
- Nous allons maintenant améliorer les vues avec Twig.
|
||||
- Repartez donc de votre précédent projet `TweetTok`.
|
||||
- **<span style="color:red">Attention! L'utilisation des commandes `symfony
|
||||
console make:crud` et `symfony console make:form` sont interdites pour le
|
||||
moment ! L'objectif est de comprendre ce qu'elles font.</span>**
|
||||
|
||||
## Ressources
|
||||
|
||||
- Documentation de Symfony sur Twig :
|
||||
[https://symfony.com/doc/5.x/templates.html](https://symfony.com/doc/5.x/templates.html)
|
||||
- Documentation de Twig :
|
||||
[https://twig.symfony.com/doc/2.x/templates.html](https://twig.symfony.com/doc/2.x/templates.html)
|
||||
|
||||
## Partie 1 : Affichage des Twoks (30 min)
|
||||
|
||||
1. **Template de base :**
|
||||
- Créez un fichier `base.html.twig` qui contient les balises `<head>` et
|
||||
`<body>` de votre page web.
|
||||
- Créez un block `body` vide qui sera rempli par les autres templates.
|
||||
|
||||
2. **Liste des Twoks :**
|
||||
- Créez un template `index.html.twig` pour afficher la liste des `Twoks`.
|
||||
Utilisez une boucle `for` pour itérer sur chaque `Twok`. Affichez le contenu
|
||||
du `Twok`, son auteur et sa date de création formatée.
|
||||
- Faites en sorte que le votre template `index.html.twig` étende le template
|
||||
`base.html.twig` pour ne pas avoir à dupliquer de code HTML.
|
||||
|
||||
3. **Filtres personnalisés :**
|
||||
- Créez un filtre Twig personnalisé pour résumer les `Twoks` qui sont trop
|
||||
longs. Implémentez le filtre dans le fichier `src/Twig/AppExtension.php`
|
||||
et nommez ce filtre `summarize`. Voir [doc sur les extension
|
||||
Twig](https://symfony.com/doc/current/templates.html#writing-a-twig-extension).
|
||||
- Utilisez ce filtre dans votre template pour afficher un résumé des `Twoks`.
|
||||
```twig
|
||||
{{ twok.content|summarize(100) }}
|
||||
```
|
||||
|
||||
## Partie 2 : Interaction avec les Twoks (45 min)
|
||||
|
||||
1. **Affichage conditionnel :**
|
||||
- Ajoutez un affichage conditionnel pour montrer un message spécial (ex: "Nouveau Twok !") si un
|
||||
`Twok` a été créé le jour même.
|
||||
|
||||
2. **Inclusion de Templates :**
|
||||
- Créez un template séparé pour afficher les détails d'un `Twok`
|
||||
(`twok_detail.html.twig`) et incluez-le dans votre liste de `Twoks`.
|
||||
|
||||
3. **Macros Twig pour les boutons :**
|
||||
- Définissez une macro Twig pour générer des boutons de like et de partage
|
||||
pour chaque `Twok`. Utilisez cette macro dans le template de détail du `Twok`.
|
||||
|
||||
## Partie 3 : Fonctionnalités Avancées (45 min)
|
||||
|
||||
1. **Affichage alterné :**
|
||||
- Expérimentez avec des structures de contrôle avancées en affichant les
|
||||
`Twoks` en alternance : un `Twok` sur fond clair, l'autre sur fond sombre.
|
||||
|
||||
2. **`Twoks` par utilisateur :**
|
||||
- Créez un nouveau template `twok_by_user.html.twig` qui permettra de lister
|
||||
l'ensemble des utilisateurs avec pour chaqun une liste de ses `Twoks`.
|
||||
|
||||
3. **Ordre des `Twoks` :**
|
||||
- Dans votre template `index.html.twig`, faites en sorte qu'il soit possible
|
||||
de lister les `Twoks` du plus ancien au plus récent et l'inverse.
|
||||
@ -1,107 +1,113 @@
|
||||
# TP5 : API Platform
|
||||
# TP6 : Renforcer la Sécurité des Applications Symfony
|
||||
|
||||
> This work is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/).
|
||||
> Permission is explicitly granted to copy, distribute and/or modify this document for educational purposes under the terms of the CC BY-NC-SA license.
|
||||
|
||||
## Objectifs
|
||||
## Objectifs :
|
||||
|
||||
Les objectifs de ce TP sont :
|
||||
|
||||
- Se familiariser avec API Platform.
|
||||
- Créer une API REST pour des opération de CRUD.
|
||||
- Comprendre les liens entre API Platform, Symfony et Doctrine
|
||||
- Renforcer la sécurité d'un projet Symfony existant en mettant en place des mesures contre les menaces courantes
|
||||
de sécurité web, telles que :
|
||||
- le Cross-Site Scripting (XSS),
|
||||
- le Cross-Site Request Forgery (CSRF),
|
||||
- en permettant l'inscription sécurisée des utilisateurs, leur connexion et déconnexion,
|
||||
- et en implémentant l'autorisation des utilisateurs en fonction des rôles.
|
||||
|
||||
## Consignes
|
||||
## Prérequis :
|
||||
|
||||
- Durée : 2 heures
|
||||
- Tous vos projets `Symfony` sont à placer votre dossier `~/public_html`.
|
||||
- N'utilisez PAS le serveur `londres.uca.local` pour tester vos pages mais la
|
||||
commande `symfony server:start`.
|
||||
- Nous allons continuer notre réseau social nommé `TweetTok` où les messages
|
||||
sont nommés des `Twok`.
|
||||
- Lors du précédent TP, nous avons réalisé un site permettant des fonctions de CRUD.
|
||||
- Nous allons maintenant implémenter une API REST pour l'administration.
|
||||
- Créez un NOUVEAU projet `TweetTokAPI` en parallèle de votre précédent projet `TweetTok`.
|
||||
- Un projet Symfony fonctionnel (votre projet `TweetTok`, votre projet Symfony, une SAE).
|
||||
|
||||
## Ressources
|
||||
|
||||
- Documentation d'API Platform :
|
||||
[https://api-platform.com/docs/distribution/](https://api-platform.com/docs/distribution/)
|
||||
|
||||
## Partie 1 : Installation de API Platform (15 min)
|
||||
|
||||
1. Installation
|
||||
|
||||
- Installer API Platform via Composer :
|
||||
```bash
|
||||
symfony new TweetTokAPI
|
||||
cd TweetTokAPI
|
||||
symfony composer require api
|
||||
symfony composer require symfony/orm-pack
|
||||
symfony composer require --dev symfony/maker-bundle
|
||||
```
|
||||
- Comparez la structure des répertoires du projet API par rapport au projet de
|
||||
site web `TweetTok`. Quels dossiers sont en plus/moins ? Le projet est-il
|
||||
plus lourd ou plus léger ?
|
||||
|
||||
2. Configurer la Base de Données :
|
||||
|
||||
- Configurer le projet pour SQLite ou POSTGRE (la même que pour les TPs précédents) :
|
||||
- Si POSTGRE :
|
||||
```bash
|
||||
DATABASE_URL="postgresql://VotreUser:VotrePass@londres/dbVotreUser"
|
||||
```
|
||||
- Si SQLite :
|
||||
```bash
|
||||
# fichier .env
|
||||
DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db"
|
||||
```
|
||||
```bash
|
||||
# On fait un lien symbolique de la BDD.
|
||||
# En pratique SQLite est à proscrire pour une archi micro-services.
|
||||
cd var && ln -s ../../TweetTok/var/data.db .
|
||||
```
|
||||
- Copiez le dossier `migrations` de votre projet `TweetTok` dans `TweetTokAPI`.
|
||||
- Créez un lien symbolique des fichiers `TweetTok/src/Entity/Twok.php` et
|
||||
`TweetTok/src/Repository/TwokRepository.php` dans le nouveau projet
|
||||
`TweetTokAPI`.
|
||||
- Effectuer les migrations pour configurer la base de données :
|
||||
```bash
|
||||
symfony console doctrine:database:create
|
||||
symfony console doctrine:migrations:migrate
|
||||
```
|
||||
|
||||
## Partie 2 : Création de Ressources pour l'API (30 minutes)
|
||||
|
||||
1. Déclarez l'entité `Twok` comme une ressource API et ajoutez des contraintes
|
||||
sur ses différents champs.
|
||||
|
||||
2. Testez votre API avec la page web (route `/api`) :
|
||||
- Si vous voyez les messages déjà insérés;
|
||||
- Si vous pouvez insérer un nouveau message;
|
||||
- Si vous pouvez modifier/remplacer un message existant;
|
||||
- Si vous pouvez supprimer un message existant;
|
||||
|
||||
3. Effectuez les mêmes tests avec les commandes cURL fournies :
|
||||
- Comprenez-vous les options de cURL dans la commande ?
|
||||
- Comprenez-vous la réponse de cURL ?
|
||||
|
||||
4. Insérez/Supprimez un message directement dans la BDD avec SQLite/POSTGRE :
|
||||
- Que constatez-vous ?
|
||||
|
||||
## Partie 3 : Génération de Code Client API
|
||||
|
||||
1. Utilisez API Platform pour générer le code d'un client de l'API dans le
|
||||
framework de votre choix
|
||||
|
||||
2. Validez que vous pouvez interagir avec l'API (lister, créer, supprimer,
|
||||
modifier, etc).
|
||||
|
||||
## Partie 4 : Pour aller plus loin
|
||||
|
||||
1. Renseignez-vous sur la création d'une classe de validation de contraintes
|
||||
personnalisée :
|
||||
[https://symfony.com/doc/5.x/validation/custom_constraint.html](https://symfony.com/doc/5.x/validation/custom_constraint.html).
|
||||
|
||||
2. Implémentez une validation personnalisée pour bloquer des messages contenant
|
||||
des mots interdits (ex: contenu insultant)
|
||||
- [Documentation de Sécurité Symfony](https://symfony.com/doc/current/security.html)
|
||||
|
||||
## Partie 1 : Protection contre les attaques XSS
|
||||
|
||||
1. Utilisez l'un de vos formulaire (ajout d'un `Twok`) pour tester un exploit
|
||||
de faille XSS (écrivez le code en JS). Que constatez-vous ?
|
||||
- Indice : Utilisez la balise `<script>` et la fonction `alert` en Javascript.
|
||||
2. Modifiez le template Twig et ajoutez le filtre `raw` lorsque vous affichez
|
||||
la variable dans laquelle vous stockez votre exploit XSS (ex : `{{
|
||||
commentaire|raw }}`). Retestez l'attaque, que constatez-vous ?
|
||||
3. Utilisez le composant `html-sanitizer` de Symfony pour permettre d'afficher
|
||||
du code (ex : un commentaire en rouge) mais sans permettre les failles XSS.
|
||||
Créez un formulaire simple pour tester les vulnérabilités XSS ou modifiez un
|
||||
formulaire existant.
|
||||
|
||||
## Partie 2 : Prévention des attaques CSRF
|
||||
|
||||
1. Vérifiez si la protection contre les CSRF est activée dans vos formulaires.
|
||||
Comment avez-vous fait ? Si elle est activée, désactivez-la.
|
||||
2. Testez un exploit d'attaque CSRF sur l'un de vos formulaires.
|
||||
- Indice : Implémentez un formulaire dans une page HTML externe au projet,
|
||||
qui fait une requête POST vers votre site cite de l'attaque. Utilisez les
|
||||
fonction Javascript `getElementById` et `submit` pour forcer le browser à
|
||||
envoyer la requête sans le consentement de l'utilisateur. Si vous êtes
|
||||
machiavélique, trouvez une façon de ne pas afficher le formulaire sur la
|
||||
page.
|
||||
3. Activez la protection CSRF dans les formulaires. Que constatez-vous ?
|
||||
Retestez votre attaque.
|
||||
4. Utilisez la commande `curl` pour envoyer une requête POST sur votre
|
||||
formulaire avec et sans le token CSRF, que constatez-vous ?
|
||||
|
||||
## Partie 3 : Inscription sécurisée des utilisateurs
|
||||
|
||||
1. Générez une entité `User` qui sera identifié avec son email et qui aura un mot de passe, avec la commande :
|
||||
```bash
|
||||
symfony console make:user
|
||||
```
|
||||
2. Générez un formulaire de login et logout pour l'entité `User` avec la commande suivante :
|
||||
```bash
|
||||
symfony console make:security:form-login
|
||||
```
|
||||
3. Générez un formulaire d'inscription pour votre entité `User` avec la commande suivante :
|
||||
```bash
|
||||
symfony console make:registration-form
|
||||
```
|
||||
|
||||
N'envoyez pas de mail de confirmation.
|
||||
|
||||
4. Utilisez des contraintes sur votre entité `User` pour vous assurer que :
|
||||
- Le mot de passe est fort : [https://symfony.com/doc/current/reference/constraints/PasswordStrength.html](https://symfony.com/doc/current/reference/constraints/PasswordStrength.html)
|
||||
- Le mot de passe est plus long que 8 charactères (contrainte sur la longueur)
|
||||
|
||||
Testez votre formulaire pour valider que ces contraintes sont bien implémentées.
|
||||
|
||||
5. Vers quelle route votre site redirige l'utilisateur losqu'il se connecte et se déconnecte ?
|
||||
|
||||
## Partie 4 : Autorisation des utilisateurs avec des rôles
|
||||
|
||||
1. Notez que l'entité `User` a une propriété `role` qui contient le rôle de
|
||||
l'utilisateur (administrateur, utilisteur, etc). Quelle est la valeur par
|
||||
défaut ?
|
||||
|
||||
2. Nous allons créer un utilisateur normal et un administrateur pour tester nos
|
||||
permissions. Exécutez la commande suivante et créez le CRUD de l'entité `User` :
|
||||
```bash
|
||||
symfony console make:crud
|
||||
```
|
||||
Modifiez le fichier `src/Form/UserType.php` crée par la commande précédente et remplacez `->add('roles')` par
|
||||
```php
|
||||
->add('roles', ChoiceType::class, [
|
||||
'choices' => [
|
||||
'ROLE_ADMIN' => 'ROLE_ADMIN',
|
||||
'ROLE_USER' => 'ROLE_USER',
|
||||
], 'multiple' => true,
|
||||
])
|
||||
```
|
||||
|
||||
3. Utilisez le formulaire d'inscription pour inscrire au moins deux
|
||||
utilisateurs et utilisez le formulaire de modification nouvellement crée
|
||||
pour modifier le rôle d'un utilisateur en administrateur.
|
||||
|
||||
|
||||
4. Restreignez l'accès aux routes en fonction des rôles des utilisateurs dans
|
||||
votre configuration de sécurité à l'aide du fichier
|
||||
`confi/packages/security.yaml` puis dans les fichiers des controlleurs (avec
|
||||
la primitive `IsGranted`) afin de restreindre les URL commençant par `/user`
|
||||
aux seuls administrateurs (le CRUD de modification des utilisateurs).
|
||||
|
||||
5. Essayer d'acceder aux URL `/user` et au reste de votre site sans être
|
||||
authentifié, en étant authentifié en tant qu'utilisateur et enfin en tant
|
||||
qu'administrateur afin de valider que votre configuration est correcte.
|
||||
|
||||
@ -1,113 +0,0 @@
|
||||
# TP6 : Renforcer la Sécurité des Applications Symfony
|
||||
|
||||
> This work is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/).
|
||||
> Permission is explicitly granted to copy, distribute and/or modify this document for educational purposes under the terms of the CC BY-NC-SA license.
|
||||
|
||||
## Objectifs :
|
||||
|
||||
Les objectifs de ce TP sont :
|
||||
|
||||
- Renforcer la sécurité d'un projet Symfony existant en mettant en place des mesures contre les menaces courantes
|
||||
de sécurité web, telles que :
|
||||
- le Cross-Site Scripting (XSS),
|
||||
- le Cross-Site Request Forgery (CSRF),
|
||||
- en permettant l'inscription sécurisée des utilisateurs, leur connexion et déconnexion,
|
||||
- et en implémentant l'autorisation des utilisateurs en fonction des rôles.
|
||||
|
||||
## Prérequis :
|
||||
|
||||
- Un projet Symfony fonctionnel (votre projet `TweetTok`, votre projet Symfony, une SAE).
|
||||
|
||||
## Ressources
|
||||
|
||||
- [Documentation de Sécurité Symfony](https://symfony.com/doc/current/security.html)
|
||||
|
||||
## Partie 1 : Protection contre les attaques XSS
|
||||
|
||||
1. Utilisez l'un de vos formulaire (ajout d'un `Twok`) pour tester un exploit
|
||||
de faille XSS (écrivez le code en JS). Que constatez-vous ?
|
||||
- Indice : Utilisez la balise `<script>` et la fonction `alert` en Javascript.
|
||||
2. Modifiez le template Twig et ajoutez le filtre `raw` lorsque vous affichez
|
||||
la variable dans laquelle vous stockez votre exploit XSS (ex : `{{
|
||||
commentaire|raw }}`). Retestez l'attaque, que constatez-vous ?
|
||||
3. Utilisez le composant `html-sanitizer` de Symfony pour permettre d'afficher
|
||||
du code (ex : un commentaire en rouge) mais sans permettre les failles XSS.
|
||||
Créez un formulaire simple pour tester les vulnérabilités XSS ou modifiez un
|
||||
formulaire existant.
|
||||
|
||||
## Partie 2 : Prévention des attaques CSRF
|
||||
|
||||
1. Vérifiez si la protection contre les CSRF est activée dans vos formulaires.
|
||||
Comment avez-vous fait ? Si elle est activée, désactivez-la.
|
||||
2. Testez un exploit d'attaque CSRF sur l'un de vos formulaires.
|
||||
- Indice : Implémentez un formulaire dans une page HTML externe au projet,
|
||||
qui fait une requête POST vers votre site cite de l'attaque. Utilisez les
|
||||
fonction Javascript `getElementById` et `submit` pour forcer le browser à
|
||||
envoyer la requête sans le consentement de l'utilisateur. Si vous êtes
|
||||
machiavélique, trouvez une façon de ne pas afficher le formulaire sur la
|
||||
page.
|
||||
3. Activez la protection CSRF dans les formulaires. Que constatez-vous ?
|
||||
Retestez votre attaque.
|
||||
4. Utilisez la commande `curl` pour envoyer une requête POST sur votre
|
||||
formulaire avec et sans le token CSRF, que constatez-vous ?
|
||||
|
||||
## Partie 3 : Inscription sécurisée des utilisateurs
|
||||
|
||||
1. Générez une entité `User` qui sera identifié avec son email et qui aura un mot de passe, avec la commande :
|
||||
```bash
|
||||
symfony console make:user
|
||||
```
|
||||
2. Générez un formulaire de login et logout pour l'entité `User` avec la commande suivante :
|
||||
```bash
|
||||
symfony console make:security:form-login
|
||||
```
|
||||
3. Générez un formulaire d'inscription pour votre entité `User` avec la commande suivante :
|
||||
```bash
|
||||
symfony console make:registration-form
|
||||
```
|
||||
|
||||
N'envoyez pas de mail de confirmation.
|
||||
|
||||
4. Utilisez des contraintes sur votre entité `User` pour vous assurer que :
|
||||
- Le mot de passe est fort : [https://symfony.com/doc/current/reference/constraints/PasswordStrength.html](https://symfony.com/doc/current/reference/constraints/PasswordStrength.html)
|
||||
- Le mot de passe est plus long que 8 charactères (contrainte sur la longueur)
|
||||
|
||||
Testez votre formulaire pour valider que ces contraintes sont bien implémentées.
|
||||
|
||||
5. Vers quelle route votre site redirige l'utilisateur losqu'il se connecte et se déconnecte ?
|
||||
|
||||
## Partie 4 : Autorisation des utilisateurs avec des rôles
|
||||
|
||||
1. Notez que l'entité `User` a une propriété `role` qui contient le rôle de
|
||||
l'utilisateur (administrateur, utilisteur, etc). Quelle est la valeur par
|
||||
défaut ?
|
||||
|
||||
2. Nous allons créer un utilisateur normal et un administrateur pour tester nos
|
||||
permissions. Exécutez la commande suivante et créez le CRUD de l'entité `User` :
|
||||
```bash
|
||||
symfony console make:crud
|
||||
```
|
||||
Modifiez le fichier `src/Form/UserType.php` crée par la commande précédente et remplacez `->add('roles')` par
|
||||
```php
|
||||
->add('roles', ChoiceType::class, [
|
||||
'choices' => [
|
||||
'ROLE_ADMIN' => 'ROLE_ADMIN',
|
||||
'ROLE_USER' => 'ROLE_USER',
|
||||
], 'multiple' => true,
|
||||
])
|
||||
```
|
||||
|
||||
3. Utilisez le formulaire d'inscription pour inscrire au moins deux
|
||||
utilisateurs et utilisez le formulaire de modification nouvellement crée
|
||||
pour modifier le rôle d'un utilisateur en administrateur.
|
||||
|
||||
|
||||
4. Restreignez l'accès aux routes en fonction des rôles des utilisateurs dans
|
||||
votre configuration de sécurité à l'aide du fichier
|
||||
`confi/packages/security.yaml` puis dans les fichiers des controlleurs (avec
|
||||
la primitive `IsGranted`) afin de restreindre les URL commençant par `/user`
|
||||
aux seuls administrateurs (le CRUD de modification des utilisateurs).
|
||||
|
||||
5. Essayer d'acceder aux URL `/user` et au reste de votre site sans être
|
||||
authentifié, en étant authentifié en tant qu'utilisateur et enfin en tant
|
||||
qu'administrateur afin de valider que votre configuration est correcte.
|
||||
Loading…
Reference in new issue