-
Pour mon projet, j'ai deux interfaces une interface pour mon front en JS/CSS/HTML et une interface back Java/Spring Boot/Hibernate/Thymleaf/CSS/HTML qui donne accès a la gestion de ma base de donné avec le CRUD et est protéger par Spring Sécurity.
Il me semblait que ce n'était pas une mauvaise construction.
Mais il me semble que tu me dit que l'interface back devrait etre aussi en JS/CSS/HTML. Ensuite que cette interface est protégé par authentification par le back et Spring Sécurity, que tout les échanges de données se font par API REST.
Et non pas par de simple "controller" comme dans mon cas, puisque mon interface fonctionne avec Spring Boot et Thymleaf.
C'est bien ce que tu essaies de m'expliquer?
-
Le Back et le Front doivent être aussi indépendant que possible.
De fait, il ne faut surtout pas utiliser thymeleaf.
J'ajouterais même que tant à faire une ihm qui dépend du Back, autant utiliser JSF qui est plus mature.
Mais JSF, malgré ses qualités, a disparu selon le principe que le client doit être indépendant du back.
Le client est une application en Javacript (ou en typescript car le Javascript, c'est vraiment de la merde) fait en général à l'aide de Angular, Vue JS ou Bootstrap. Le client est indépendant et n'a besoin du serveur que pour récupérer les données.
A noter que l'on peut éventuellement scalabiliser les client (un web, un lourd, un androïd...).
Le serveur sert à donner les données.
Bien, jusqu'ici, j'ai rien dit de transcendant.
Seulement, les données, que l'on modifie où auxquelles on accède dépendent des utilisateurs et des rôles. C'est là que Spring Security intervient.
Avant
Une partie était gérée en session (époque de JSF par exemple). Et l'IHM est gérée en partie par le serveur. De fait, on se connectait une fois et tout était gardé en session (utilisateurs et rôles).
Rappel: Une page était géré par le serveur et en web 2.0, on rechargeait une partie de la page par le serveur.
Aujourd'hui
Le client est un programme indépendant (cf Angular) et il se remet à jour tout seul, en s'aidant des données envoyé par le serveur.
Ce principe implique que la page de connexion est dans le code du client.
Le formulaire de connexion est géré par le client et ne doit en aucun cas être géré par Spring!
Rien que le cas du "j'ai oublier mon mail ou mon password" est une des fonctionnalité qui doit pouvoir être disponible côté client!
Comment faire?
De fait, on utilise un JWT.
Le formulaire de connexion envoi au serveur login/password.
Le serveur vérifie donc grâce au login et au password que l'on a un utilisateur existant, et il en profite pour envoyer les rôles.
Cet utilisateur est en BDD mais il peut aussi être dans un LDAP voir les 2.
A partir de ces données, il va construire un jeton JWT qu'il va renvoyer au client.
Le client va donc garder en mémoire ce jeton.
Et quand il va demander à utiliser un autre service, il va passer en entête ce jeton.
Et à chaque fois qu'un service est appelé, le serveur va décoder le jeton et ça va lui permettre de savoir si le service peut être appelé.
-
1 pièce(s) jointe(s)
Et pour en revenir à ton code, je pense que tu as la page de login justement gérée par Spring, un peut comme celle-ci:
Pièce jointe 632697
-
1 pièce(s) jointe(s)
Vraiment merci pour tes explications, là au moins j'ai une bonne vision de ce qui se fait dans le domaine pro, cela va me permettre de m'orienter en fonction.
J'avais prévu de me mettre à apprendre un framework front, par contre tu parle d'Angular, mais je comptait m’intéresser à React.
A tu un avis sur la question?
Sachant que je ne connais pas le Typescript.
Tes conseils me seront précieux car je suis à la recherche d'un stage en back.
Sinon pour ma page de login, non ce n'est pas la page par défaut, la page par défaut est remplacé par une page perso si on respecte certaines conditions.
Voici la page qui s'affiche, elle est en HTML brut, je n'ai pas fait de CSS:
Pièce jointe 632724
-
1 pièce(s) jointe(s)
Justement, sur l'image, ça se voit clairement, c'est Spring qui génère la page HTML (adresse localhost:8080).
Mais justement, en ce qui me concerne, le client n'a rien à voir avec le serveur et vit sa vie "indépendamment" du serveur. C'est 2 applications distinctes
Pièce jointe 632734
Sur cette capture d'écran, c'est l'application cliente (lancé par du node.js, localhost:3000) qui a toute la logique cliente et qui porte, entre autre, le formulaire de connexion.
Au pire, je peux scalabiliser les applications clientes (au moins en théorie) comme de l'android, ou voir d'autre web-service, sans avoir à passer par le formulaire Spring.
Pour moi, l'application serveur n'a plus à gérer un formulaire de connexion.
Je pense vraiment que ce n'est pas une bonne façon de laisser Spring gérer le formulaire de connexion.
-
Après, pour être honnête, je ne connais pas React que j'ai juste survolé sur Wikipédia.
Mais je recommande plutôt Angular à React et ceci pour 2 raisons:
1) Javascript est un vrai langage de merde (élu pour la 4ème fois langage détesté des développeur https://programmation.developpez.com...agez-vos-avis/ ). Angular recommande Typescript, qui est Object, et typé.
2)En lisant Wikipédia ( ou autre tutoriel https://fr.reactjs.org/tutorial/tutorial.html ), le code React mélange du code HTML/CSS/Javascript. Or, c'est justement une mauvaise pratique. Les finalités du CSS, du Javascript et du HTML ne sont pas les même. C'est pour ça que c'est 3 fichier sont distincts dans un projet normal.
Le point 2 est la principale raison pour laquelle je déteste un framework comme svelte qui a franchement eu ma peau.
L'entrée pour Angular est effectivement plus élevé, mais le code au final est mieux architecturé, écrit avec un vrai langage de programmation (Type Script).
Et pour la durabilité d'un projet, c'est la qualité du code qui prime, pas la performance et l'optimisation.
J'ai d'ailleurs repris mon IHM sur mon projet, ou je vais supprimer JavaFX pour remplacer par angular (branche feature/client-web pour l'instant):
https://bitbucket.org/philippegibaul...r40k/src/main/
