Discussion :

[SylvainPV]

Bien évidemment, ce genre de règles métier est implémenté en back. "Never trust client", ça reste vrai SPA ou non. Quand tu as parlé de sécurité, je ne pensais pas qu'on devait en revenir aux bases

[adaptable_aniforme]

Bien évidemment, ce genre de règles métier est implémenté en back

Tu n'as toujours pas compris où je vais en venir . Bon , c'est pas la peine de continuer parce que tu ne comprendras pas d'ailleurs. Tu n'as surement jamais travaillé sur de très grosses applications de gestion , donc tu n'en as aucune idée de quoi je parle.

Toi , çà signifie en gros que c'est la fluidité d'une application qui est mise en avant, c'est le front, le design , le javascript , l'AngularJS , etc.
Moi, je suis plutôt profil back lourd où il y a des tonnes de traitement en back , et que le front c'est juste une petite interface où chaque bouton correspond déjà à un traitement très complexe, voir équivalent à une application. En bref, si on venait à me demander de migrer une telle application vers du SPA , c'est de la folie pure et je préfèrerai démissionner au risque de me faire pendre.

En bref , même si nous sommes tous deux développeurs , nous sommes dans 2 mondes très différents et nos 2 besoins ne seront donc jamais le même.

[SylvainPV]

Je ne vais pas te parler de mon poste actuel alors, ça risquerait de te remettre en question

Sur ce, je vais modifier le JS de mon site bancaire pour me faire du fric

[adaptable_aniforme]

je vais modifier le JS de mon site bancaire pour me faire du fric

Je l'espère pour toi en tous cas

Si seulement j'étais dans des contextes moins contraignants que toi , je serais très heureux de ma vie d'Architecte développeur. La vie serait belle

[Marco46]

Vous ne comprenez pas de quoi je parle , donc je vais vous donner un exemple simple.

On a très bien compris t'inquiète.

Exemple: voici la règle de gestion dans une petite application de gestion
" si le client a tapé une qté > 50 , proposer lui une réduction de 20%
si vous envoyez à l'api REST la quantité 50 , alors l'API REST renverra la réduction de 20%"

Donc il suffit au hacker le plus bête de modifier la condition javascript pour contourner çà et il reçoit
la réduction

Noooon ... Sérieusement ???

Dans ce cas, évidemment, tu exécutes cette règle côté back, ou bien tu contrôles côté back en réexécutant la règle métier.

A moins de supprimer toutes les conditions javascript(les if , les for , les while , etc ) dans votre AngularJS, je ne vois pas comment vous pourriez vous protégez de tous çà.

Tu les exécutes côté back. Et il te restera un nombre pas croyable de règles qui n'ont pas cette contrainte à implémenter côté front, t'inquiète pas.

[Marco46]

En bref, si on venait à me demander de migrer une telle application vers du SPA , c'est de la folie pure et je préfèrerai démissionner au risque de me faire pendre.

C'est mieux de démissionner en effet, tu es clairement incompétent sur ce type d'architecture.

[nathieb]

Bonjour,

Je suis déçu par ce manque de confiance évident, comme si on faisait confiance au front.
En règle général les règles métiers sont codés côté REST, voir dupliqué pour le contrôle.
Il existe plusieurs moyen de créer une frontière sécurisé côté serveur

{[xxxx]} : optionnel

AngularJS avec code métier et service simples non sécurisés <------------> REST API <----------> Code métier de contrôle et validation <---> API Base <---> {[PL/SQL]} <----> Base

Dans Angular on gère la présentation comme dans un appli type PHP standard, quand vous faîtes de l'ajax, vous êtes dans le même contexte
de non sécurité, vous devez donc doubler les contrôles. C'est la base du dev web, on ne fait jamais confiance au frontal !

Une architecture se construit et se pense, les spécs sont là pour cela.
- les tests fonctionnels
- les tests d'intrusions aussi
Olivier

[adaptable_aniforme]

Dans ce cas, évidemment, tu exécutes cette règle côté back, ou bien tu contrôles côté back en réexécutant la règle métier.

Là, vous me parlez de dupliquer la sécurité Front avec la sécurité Back.
Donc , vous avez fini par admettre qu'AngularJS n'est pas sécurisée(car Front) et ne peut pas se la faire et qu'en fin de compte il faut toujours Java EE/.Net/Symfony , SPA ou pas vous ne pourriez jamais vous passer des bons vieux Java EE/.NET/Symfony.

Cela dit, vous auriez toujours besoin de doubler tous les contrôles métiers dans l'API REST et donc de doubler le travail de développement dans la majorité des cas
Au lieu d'avoir fini l'application entière en 30 jours(Symfony + JQuery) , vous n'allez finir l'application qu'en 50 jours(API REST Symfony + client AngularJS)

[Watilin]

Là, vous me parlez de dupliquer la sécurité Front avec la sécurité Back.
Donc , vous avez fini par admettre qu'AngularJS n'est pas sécurisée(car Front) et ne peut pas se la faire et qu'en fin de compte il faut toujours Java EE/.Net/Symfony , SPA ou pas vous ne pourriez jamais vous passer des bons vieux Java EE/.NET/Symfony.

Ce que tu viens de dire ressemble fort à un sophisme !
Il y a toujours eu une sécurité côté back, et cette securité-là, hors de question de s’en passer. Si les autres n’en ont pas parlé c’est parce que ça ne leur venait même pas à l’esprit que quelqu’un la remettrait en question. Oui, la sécurité de la logique métier se fait côté back, car comme l’ont dit Sylvain et nathieb, never trust client est la règle d’or.

Angular donne simplement une façon de concevoir qui permet d’appliquer plus facilement la sécurité en back. Et oui effectivement on doit coder deux fois la logique métier, mais pas dans le même but : côté back on le fait pour la sécurité, côté front on le fait pour le confort de l’utilisateur.

Tout le monde, on arrête les attaques ad hominem s’il vous plaît, ce n’est pas ça qui fait avancer le débat

[Marco46]

Là, vous me parlez de dupliquer la sécurité Front avec la sécurité Back.
Donc , vous avez fini par admettre qu'AngularJS n'est pas sécurisée(car Front) et ne peut pas se la faire et qu'en fin de compte il faut toujours Java EE/.Net/Symfony , SPA ou pas vous ne pourriez jamais vous passer des bons vieux Java EE/.NET/Symfony.

Il n'y a aucune sécurité côté front, parce que le front en SPA est entièrement public. En quelle langue faut-il te l'écrire ?

Il n'a jamais été question de se passer des services REST, simplement du templating côté serveur.

Cela dit, vous auriez toujours besoin de doubler tous les contrôles métiers dans l'API REST et donc de doubler le travail de développement dans la majorité des cas
Au lieu d'avoir fini l'application entière en 30 jours(Symfony + JQuery) , vous n'allez finir l'application qu'en 50 jours(API REST Symfony + client AngularJS)

Même si tu fais du templating côté serveur, à partir du moment où tu vas faire un peu d'Ajax il va bien falloir que tu doubles tes traitements de contrôle. Ou alors tu contrôles seulement côté back et dans ce cas bonjour la réactivité de l'interface si tu dois faire des A/R avec le serveur pour check qu'une condition soit bien remplie ou une règle appliquée.

Bref, si tu as envie de rester dans ta zone de confort qui a 10 ans ça te regarde, mais inutile de venir polluer ce fil de discussion avec tes remarques idiotes.

Angular donne simplement une façon de concevoir qui permet d’appliquer plus facilement la sécurité en back.

C'est pas angular, c'est les SPA. Que ce soit angular ou emberjs c'est pareil.

Et oui effectivement on doit coder deux fois la logique métier, mais pas dans le même but : côté back on le fait pour la sécurité, côté front on le fait pour le confort de l’utilisateur.

Oui ! Mais pas seulement.

Admettons un formulaire avec un champ de saisie qui est un n° de SIREN. Tu peux coder côté front l'algo de validité du SIREN. Ca ne te décharge pas de le faire côté back. Simplement l'utilisateur dans la plupart des cas (sauf s'il hack pour désactiver les contrôles front en fait) ne va requêter (et donc utiliser des ressources serveurs) le back QUE lorsque le SIREN sera valide.

Ca aussi ça a un impact important sur les perfs de l'ensemble.

[adaptable_aniforme]

Bref, si tu as envie de rester dans ta zone de confort qui a 10 ans ça te regarde, mais inutile de venir polluer ce fil de discussion avec tes remarques idiotes.
.

Comme a dit Watilin , arrêtes d'attaquer les gens parce que toi aussi tu es très bête à mes yeux

Angular donne simplement une façon de concevoir qui permet d’appliquer plus facilement la sécurité en back. Et oui effectivement on doit coder deux fois la logique métier, mais pas dans le même but : côté back on le fait pour la sécurité, côté front on le fait pour le confort de l’utilisateur.
Tout le monde, on arrête les attaques ad hominem s’il vous plaît, ce n’est pas ça qui fait avancer le débat

+1
Voilà au moins une personne de sensé sur ce débat et qui raisonne de façon logique et claire.

Merci Watilin d'avoir confirmé mes pensées

[ABCIWEB]

Au lieu d'avoir fini l'application entière en 30 jours(Symfony + JQuery) , vous n'allez finir l'application qu'en 50 jours(API REST Symfony + client AngularJS)

Bah oui c'est comme pour tous les framework, si leur emploi ne se traduit pas en terme de gain de productivité/maintenance/efficacité il n'y a pas d'intérêt à les utiliser. Je comprends donc assez ta réaction contre l'idée (puérile ?) qui laisserait penser que "tout ce qui n'est pas fait avec angular appartient au passé". Sans doute le besoin de se rassurer en pensant avoir LE nouveau standard universel et que le temps passé à l'étudier ne sera pas du temps perdu. A mon avis qu'il devienne un standard dans certains contextes, certainement, mais dans tous les contextes, certainement pas. Tout comme certains développeurs php n'utilisent pas Symfony au profit de micro framework pour avoir plus de souplesse, je ne vois pourquoi ce serait différent côté javascript. Angular s'imposera peut-être côté javascript en tant que framework lourd mais de là à ce qu'il devienne incontournable dans tous les cas, c'est très peu probable.

[beekeep]

Vous vous faite magnifiquement troller, et c'est plutôt amusant à lire

[adaptable_aniforme]

certains développeurs php n'utilisent pas Symfony au profit de micro framework pour avoir plus de souplesse, je ne vois pourquoi ce serait différent côté javascript.

+1
Tout à fait.
Ce n'est pas symfony qui est meilleur pour n'importe quel projet php, mais le framework le plus adapté à ce projet.

Angular s'imposera peut-être côté javascript en tant que framework lourd mais de là à ce qu'il devienne incontournable dans tous les cas, c'est très peu probable.

+1
Rien qu'avec çà , çà me réconforte.
Merci ABCIWEB , tu as bien résumé mes pensées

Cela dit :
- si je n'ai que peu de code javascript dans mon application, nul besoin d'AngularJS , Jquery ou javascript pur ou petit framework maison me suffirait
- si j'ai beaucoup de code javascript dans mon application et un besoin obligatoire de fluidité , là il faut choisir le SPA avec AngularJS