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/).
|
> 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.
|
> 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/).
|
> 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.
|
> 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 :
|
Les objectifs de ce TP sont :
|
||||||
|
|
||||||
- Se familiariser avec API Platform.
|
- Renforcer la sécurité d'un projet Symfony existant en mettant en place des mesures contre les menaces courantes
|
||||||
- Créer une API REST pour des opération de CRUD.
|
de sécurité web, telles que :
|
||||||
- Comprendre les liens entre API Platform, Symfony et Doctrine
|
- 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
|
- Un projet Symfony fonctionnel (votre projet `TweetTok`, votre projet Symfony, une SAE).
|
||||||
- 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`.
|
|
||||||
|
|
||||||
## Ressources
|
## Ressources
|
||||||
|
|
||||||
- Documentation d'API Platform :
|
- [Documentation de Sécurité Symfony](https://symfony.com/doc/current/security.html)
|
||||||
[https://api-platform.com/docs/distribution/](https://api-platform.com/docs/distribution/)
|
|
||||||
|
## Partie 1 : Protection contre les attaques XSS
|
||||||
## Partie 1 : Installation de API Platform (15 min)
|
|
||||||
|
1. Utilisez l'un de vos formulaire (ajout d'un `Twok`) pour tester un exploit
|
||||||
1. Installation
|
de faille XSS (écrivez le code en JS). Que constatez-vous ?
|
||||||
|
- Indice : Utilisez la balise `<script>` et la fonction `alert` en Javascript.
|
||||||
- Installer API Platform via Composer :
|
2. Modifiez le template Twig et ajoutez le filtre `raw` lorsque vous affichez
|
||||||
```bash
|
la variable dans laquelle vous stockez votre exploit XSS (ex : `{{
|
||||||
symfony new TweetTokAPI
|
commentaire|raw }}`). Retestez l'attaque, que constatez-vous ?
|
||||||
cd TweetTokAPI
|
3. Utilisez le composant `html-sanitizer` de Symfony pour permettre d'afficher
|
||||||
symfony composer require api
|
du code (ex : un commentaire en rouge) mais sans permettre les failles XSS.
|
||||||
symfony composer require symfony/orm-pack
|
Créez un formulaire simple pour tester les vulnérabilités XSS ou modifiez un
|
||||||
symfony composer require --dev symfony/maker-bundle
|
formulaire existant.
|
||||||
```
|
|
||||||
- Comparez la structure des répertoires du projet API par rapport au projet de
|
## Partie 2 : Prévention des attaques CSRF
|
||||||
site web `TweetTok`. Quels dossiers sont en plus/moins ? Le projet est-il
|
|
||||||
plus lourd ou plus léger ?
|
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. Configurer la Base de Données :
|
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,
|
||||||
- Configurer le projet pour SQLite ou POSTGRE (la même que pour les TPs précédents) :
|
qui fait une requête POST vers votre site cite de l'attaque. Utilisez les
|
||||||
- Si POSTGRE :
|
fonction Javascript `getElementById` et `submit` pour forcer le browser à
|
||||||
```bash
|
envoyer la requête sans le consentement de l'utilisateur. Si vous êtes
|
||||||
DATABASE_URL="postgresql://VotreUser:VotrePass@londres/dbVotreUser"
|
machiavélique, trouvez une façon de ne pas afficher le formulaire sur la
|
||||||
```
|
page.
|
||||||
- Si SQLite :
|
3. Activez la protection CSRF dans les formulaires. Que constatez-vous ?
|
||||||
```bash
|
Retestez votre attaque.
|
||||||
# fichier .env
|
4. Utilisez la commande `curl` pour envoyer une requête POST sur votre
|
||||||
DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db"
|
formulaire avec et sans le token CSRF, que constatez-vous ?
|
||||||
```
|
|
||||||
```bash
|
## Partie 3 : Inscription sécurisée des utilisateurs
|
||||||
# On fait un lien symbolique de la BDD.
|
|
||||||
# En pratique SQLite est à proscrire pour une archi micro-services.
|
1. Générez une entité `User` qui sera identifié avec son email et qui aura un mot de passe, avec la commande :
|
||||||
cd var && ln -s ../../TweetTok/var/data.db .
|
```bash
|
||||||
```
|
symfony console make:user
|
||||||
- Copiez le dossier `migrations` de votre projet `TweetTok` dans `TweetTokAPI`.
|
```
|
||||||
- Créez un lien symbolique des fichiers `TweetTok/src/Entity/Twok.php` et
|
2. Générez un formulaire de login et logout pour l'entité `User` avec la commande suivante :
|
||||||
`TweetTok/src/Repository/TwokRepository.php` dans le nouveau projet
|
```bash
|
||||||
`TweetTokAPI`.
|
symfony console make:security:form-login
|
||||||
- Effectuer les migrations pour configurer la base de données :
|
```
|
||||||
```bash
|
3. Générez un formulaire d'inscription pour votre entité `User` avec la commande suivante :
|
||||||
symfony console doctrine:database:create
|
```bash
|
||||||
symfony console doctrine:migrations:migrate
|
symfony console make:registration-form
|
||||||
```
|
```
|
||||||
|
|
||||||
## Partie 2 : Création de Ressources pour l'API (30 minutes)
|
N'envoyez pas de mail de confirmation.
|
||||||
|
|
||||||
1. Déclarez l'entité `Twok` comme une ressource API et ajoutez des contraintes
|
4. Utilisez des contraintes sur votre entité `User` pour vous assurer que :
|
||||||
sur ses différents champs.
|
- 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)
|
||||||
2. Testez votre API avec la page web (route `/api`) :
|
|
||||||
- Si vous voyez les messages déjà insérés;
|
Testez votre formulaire pour valider que ces contraintes sont bien implémentées.
|
||||||
- Si vous pouvez insérer un nouveau message;
|
|
||||||
- Si vous pouvez modifier/remplacer un message existant;
|
5. Vers quelle route votre site redirige l'utilisateur losqu'il se connecte et se déconnecte ?
|
||||||
- Si vous pouvez supprimer un message existant;
|
|
||||||
|
## Partie 4 : Autorisation des utilisateurs avec des rôles
|
||||||
3. Effectuez les mêmes tests avec les commandes cURL fournies :
|
|
||||||
- Comprenez-vous les options de cURL dans la commande ?
|
1. Notez que l'entité `User` a une propriété `role` qui contient le rôle de
|
||||||
- Comprenez-vous la réponse de cURL ?
|
l'utilisateur (administrateur, utilisteur, etc). Quelle est la valeur par
|
||||||
|
défaut ?
|
||||||
4. Insérez/Supprimez un message directement dans la BDD avec SQLite/POSTGRE :
|
|
||||||
- Que constatez-vous ?
|
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` :
|
||||||
## Partie 3 : Génération de Code Client API
|
```bash
|
||||||
|
symfony console make:crud
|
||||||
1. Utilisez API Platform pour générer le code d'un client de l'API dans le
|
```
|
||||||
framework de votre choix
|
Modifiez le fichier `src/Form/UserType.php` crée par la commande précédente et remplacez `->add('roles')` par
|
||||||
|
```php
|
||||||
2. Validez que vous pouvez interagir avec l'API (lister, créer, supprimer,
|
->add('roles', ChoiceType::class, [
|
||||||
modifier, etc).
|
'choices' => [
|
||||||
|
'ROLE_ADMIN' => 'ROLE_ADMIN',
|
||||||
## Partie 4 : Pour aller plus loin
|
'ROLE_USER' => 'ROLE_USER',
|
||||||
|
], 'multiple' => true,
|
||||||
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).
|
|
||||||
|
3. Utilisez le formulaire d'inscription pour inscrire au moins deux
|
||||||
2. Implémentez une validation personnalisée pour bloquer des messages contenant
|
utilisateurs et utilisez le formulaire de modification nouvellement crée
|
||||||
des mots interdits (ex: contenu insultant)
|
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