Dev back-end
Développement d'applications arrière-guichet
Grille d'évaluation
- Projet
- Exposer une API conforme aux spécifications
- Respect du protocol HTTP (codes retours, type de requête)
- Sécurisation de l'API (injections, xss)
- Authentification et autorisation
- Persistance des données en base
- Web sockets
- Architecture logicielle et concepts
- Architectures (en couches, micro-services)
- API et Standards (REST, GrahQL, …)
- Sécurité (SSL, Cookies, auth*)
- Stratégies de tests
- Frameworks (Symfony, Laravel, express, hapi.js)
- Message brokers (RabbitMQ, Kafka)
- Moteurs de recherche (Elastic Search, solr, Sphinx)
- Serveurs web (Apache, nginx)
- Persistance d'une session dans une application stateless (redis, memcache)
Evaluation du 3 décembre 2019
- Importer la Collection Postman
- Importer l'Environnement Postman
- Lancer le serveur d'API Haxe ou Go
- Jouer la collection
- Faites évoluer le serveur jusqu'à ce que tous les tests passent
Évaluation du 14/01/2020
- Expliquer la différence entre une autorisation et une authentification
- Lister les différentes étapes d'une authentification utilisant la mécanique des cookies
- Dans la collection Postman importée précédement
- Créer un nouveau dossier "Save"
- Y ajouter une requête nommée "/save" de type "POST", envoyant un body avec 2 paramètres
"username" et "data".
username sera un des utilisateurs connus de votre serveur web
data aura la valeur {score: 13}
- Créer un test pour valider le retour 200 de l'API
- Créer un test pour valider que la requête retourne un body en JSON qui contient une clé
"score" ayant pour valeur 13
- Implémenter le service "/save" dans votre serveur web de sorte que les tests passent.
Évaluation du 19/01/2020
- Expliquer les étapes nécessaires pour :
- stocker un mot de passe de façon sécurisée,
- comparer le mot de passe d'un utilisateur au mot de passe précédemment enregistré.
La méthode proposée devra protéger le mot de passe d'un vol de donnée et d'une extraction
bruteforce au dictionnaire.
-
Sur projet :
- Les codes http utilisés sont corrects (200, 401, 403, 500).
- L'api d'inscription et authentification est fonctionnelle et sécurisée.
- Les inscriptions sont persistantes en base de données.
- L'application comporte une couche d'accès aux données. (les requêtes SQL sont séparées
du reste)
- OU si autre découpage, le choix d'architecture est argumenté de façon détaillé
- Le serveur websocket est fonctionnel et sécurisé (ticket)
Sera corrigé le 17 février. Fournir un lien vers un dépôt git publique (gihub, gitlab ou
bitbucket par ex.)