AppLogicielPFE

Dino Runner est un jeu de type endless runner développé avec Java Swing, inspiré du célèbre "Dino Game" de Google Chrome. Dans ce projet, j'ai mis en œuvre mes compétences en programmation Java, conception d'interface utilisateur et développement de mécaniques de jeu. Le joueur contrôle un T-Rex qui doit éviter des obstacles dans un désert sans fin

Enoncé du Mini-Projet Mini-projet à réaliser et à rendre à deux Comptera à 50% dans votre note finale. Dans le cadre de ce mini-projet vous allez devoir réaliser toute la spécification d'une API ReST dans un premier temps, puis le développement de cette API dans un second temps Le besoin Vous souhaitez proposer à vos utilisateurs une API qui permettra de gérer le fonctionnement d'une messagerie instantanée type Discord Sur cette messagerie, un Utilisateur doit pouvoir : S'inscrire sur n'importe quel serveur (les serveurs sont ouverts à tous les utilisateurs) Quitter un serveur Créer un serveur (il en devient administrateur) Poster un message sur un channel d'un des serveurs sur lesquels il est inscrit Editer ou supprimer un message qu'il a lui même posté Voir les messages de tous les utilisateurs sur chacun des channels auxquels il a accès Un Administrateur est un Utilisateur un peu spécial, possédant un plus haut niveau de permissions sur un ou plusieurs serveurs. En plus des actions d'un Utilisateur, il peut aussi : Editer et supprimer un serveur sur lequel il est administrateur Créer, éditer et supprimer un channel (sur un serveur sur lequel il est administrateur) Désinscrire un utilisateur d'un serveur (sur lequel il est administrateur) Supprimer tout message de n'importe quel utilisateur (y compris d'un autre administrateur) sur un serveur sur lequel il est administrateur Enfin, un administrateur peut aussi nommer administrateur un autre utilisateur inscrit sur un serveur sur lequel il est administrateur L'objectif de votre API est de permettre à vos partenaires de développer des clients pouvant être des clients légers, des Progressive Web App ou des clients lourds. Votre API sera un CRUD tournant autour des notions d'utilisateurs, administrateurs, serveurs, channels et messages. 1ère étape - Spécifications (8 points) Vous allez commencer par créer la spécification de cette API, et plus précisément : Toute la description des ressources et des end-points nécessaires La documentation complète de l'API Vous ferez ce travail au format OpenAPI et utiliserez l'éditeur OpenAPI de votre choix (Swagger, Stoplight, Apibldr, ...). L'API que vous définirez doit couvrir tous les besoins basiques de la messagerie instantanée. De plus, il est souhaité que votre API soit HATEOAS (niveau 3 du modèle de Maturité de Richardson). Vous êtes libre d'utiliser ou non un format normé de réponse (JSON-LD, HAL, JSON-API etc ...), la note ne tiendra pas compte de ce choix. La pertinence des choix de conception que vous ferez sera cependant prise en compte dans la note. Enfin, vous devrez documenter autant que possible chaque fonctionnalité, chaque end-point, l'objectif étant que cette documentation soit totalement suffisante pour vos utilisateurs pour exploiter l'intégralité des fonctionnalités de votre API. Cette documentation devrait aussi permettre à quelqu'un qui souhaiterait implémenter votre API de pouvoir le faire. 2ème étape - Sécurité (4 points) En plus du travail de spécification à réaliser, vous rédigerez également un document de sécurité détaillant tout ce qu'il faudra/faudrait mettre en place (d'un point de vue technique) pour répondre au mieux aux besoins suivant : L'accès à votre API sera gratuit, chaque utilisateur utilisant votre messagerie instantanée communiquera avec votre API, il faudra obligatoirement authentifier les utilisateurs. Et une fois l'utilisateur authentifié, il faudra s'assurer qu'il a bien les autorisations nécessaires pour effectuer l'action intentée. Une utilisateur n'ayant pas la permission de réaliser une action devra recevoir un code HTTP approprié. Vous ne voulez pas qu'un utilisateur puisse flooder un serveur. Que faire pour garder le contrôle ? L'API doit être robuste aux principales failles du top 10 API OWASP. Les attaques de type injection (SQL, XSS etc) ne doivent notamment pas réussir. Vous expliquerez au mieux ce qui vous semble le plus pertinent à mettre en place pour répondre à tous ces besoins, en vous appuyant sur les solutions vues en cours ainsi que sur vos recherches. Vous expliquerez aussi les limites de ces solutions. 3ème étape - Mise en œuvre (8 points) Dans la mesure du possible, vous tenterez de réaliser une mise en œuvre de l'API que vous venez de spécifier. Il est vous est conseillé de développer votre API avec Node.js, même si vous restez libres de choisir une autre technologie (Java, PHP, Python, ...). Si vous ne choisissez pas Node.js, vous expliquerez les raisons de votre choix. Vous pouvez vous inspirer de ce tuto pour débuter votre API : https://practicalprogramming.fr/node-js-api Vous devrez aussi créer une base de données dans une technologie adaptée au langage que vous avez choisi. Vous pouvez par exemple utiliser le service cloud MongoDB Atlas si vous développez votre API avec Node.js, votre base de données sera ainsi déjà hébergée. L'objectif est dans un premier temps d'avoir une API pleinement fonctionnelle et conforme à vos spécifications. Ensuite vous tenterez d'appliquer les solutions en terme de sécurité que vous avez évoquées à l'étape précédente. Vous êtes libres d'utiliser les frameworks et/ou librairies de votre choix. Vous trouverez de l'aide sur les middlewares à utiliser avec Node.js et Express pour gérer les token sur cette page : https://developer.okta.com/blog/2019/02/14/modern-token-authentication-in-node-with-express Vous déposerez votre code complet sur un repository public de gitHub et vous expliquerez dans le readme de ce repository toutes les étapes à réaliser pour récupérer votre code et le faire fonctionner en local. L'API doit pouvoir être redéployée et fonctionnelle en suivant ces indications. Objectif : en s'appuyant sur votre spécification, et en utilisant Postman, toutes les opérations du CRUD doivent être réalisables sur votre API une fois celle-ci déployée Il ne vous est pas demandé de développer un CLIENT à votre API. Si vous n'arrivez pas à tout coder, et que vous procédez à des simplifications, vous expliquerez les différences entre la spécification et le développement. Rendu du projet Vous déposerez sur Moodle une archive zip au nom du binôme, contenant les éléments suivant : Un export de la spécification de votre API au format OpenAPI (format JSON ou YAML) Un fichier texte readme.txt contenant l'URL vers le repository gitHub contenant le code de votre API Le fichier de sécurité expliquant les choses à mettre en place d'un point de vue de la sécurité (.doc, .pdf, .ppt, ...)

Projet conception et developpement JAVA, création du jeu "Zeldiablo".