Discussion :

[redoran]

disant que j'ai terminé le gros de mon application.
tous mes contrôles sont en php pourquoi ?
Code exécuté coté serveur alors + de sécurité.
Si l'utilisateur désactive le js mon code continue a tourné.
Je pensé que si mon code ne tourne pas faute de désactivation du js est une faille devant l'audit.

constatations:

1. j'ai vue pas mal de site web de référence ( google) si on désactive js pas mal de module s'arrête , apparemment c'est une action toléré par rapport au bénéfice d'utilisation du js.
   
2. faut allégé la charge du serveur.

Questions:
Quel sont les critères de choix entre PHP et JS par rapport aux unités de codes?
Faut-il pour un seul contrôle faire en double contrôle en js ensuite un deuxième en PHP ?

[Seb33300]

La règle est simple : Toujours faire ses contrôles coté serveur.

Concernant les formulaires par exemple, tu peux envisager de mettre en place des pré-contrôles javascript. C'est d'une part beaucoup plus rapide que de recharger une page complète et ça soulagera un peu ton serveur.

Après, il y a certaines applications qui vont être dépendante de javascript et qui ne fonctionneront pas si il n'est pas activé. Mais ce n'est pas pour autant qu'il faut délaisser les contrôles coté serveur parce qu'il peuvent représenter des failles de sécurités sérieuses.

[grunk]

Les contrôles coté JS c'est du confort pour l'utilisateur rien de plus.

Que des modules ne fonctionnent pas de car le JS est désactivé ne me choque pas. Quand on fait tout une interface avec du drag n drop par exemple on va pas s'amuser à faire un fallback pour les 4 mecs qui n'auront pas de JS.

Il faut t'adapter au public que tu vises. Si tu sais que ton appli/site est destinée à des utilisateurs en environnement ultra sécurisé , tu vas sans doute te passer de javascript.

[redoran]

@ seb :

La règle est simple : Toujours faire ses contrôles coté serveur.

c'est mon idée de départ tous les contrôles sont en php.

Concernant les formulaires par exemple, tu peux envisager de mettre en place des pré-contrôles javascript. C'est d'une part beaucoup plus rapide que de recharger une page complète et ça soulagera un peu ton serveur.

là je crois qu'il y a un grand risque sur le plan sécurité ; alors double contrôle ( js et php) donc sa revient au php.

@ grunck

Il faut t'adapter au public que tu vises. Si tu sais que ton appli/site est destinée à des utilisateurs en environnement ultra sécurisé , tu vas sans doute te passer de javascript.

sur plan charge de travail du serveur sa donne quoi ?

donc mot clés qui ressort du post : utilisateur - sécurité - charge de travail

[grunk]

sur plan charge de travail du serveur sa donne quoi ?

Sauf cas très particulier une validation de formulaire ça représente rien du tout en terme de charge serveur.

là je crois qu'il y a un grand risque sur le plan sécurité ; alors double contrôle ( js et php) donc sa revient au php.

Y'a aucun risque de sécurité tant que tu fait es validations coté PHP. La validation js c'est juste du cosmétique pour rendre la vie plus simple à ton utilisateur.

En général c'est pas sur les formulaire que les problème de performances apparaissent

[Bovino]

La question de la charge de travail du serveur n'a aucun sens lorsque les vérifications sont faites côté client !

Pour résumer ce qui a été dit :

• la vérification côté client (JavaScript) n'a rien à voir avec la sécurité, il s'agit juste d'indiquer aux utilisateurs de bonne foi qu'il y a une erreur de saisie et ce avant de passer par le serveur, ils peuvent donc rectifier leur saisie avant de soumettre le formulaire ;
• la vérification côté serveur (PHP) sert d'abord à vérifier le format des données reçues ;
• la vérification côté serveur (PHP) sert ensuite et surtout à vérifier les données envoyées par des utilisateurs mal intentionnés, qui sauront facilement contourner les vérifications côté client et qui cherchent une faille dans ton appli pour en prendre le contrôle.

Bref, comme déjà dit, côté client, il s'agit surtout d'un agrément utile pour l'utilisateur afin de le prévenir que ce qu'il a entré comme données n'est pas conforme au format souhaité, côté client, la vérification sert essentiellement à se prémunir d'attaques malicieuses.

[redoran]

Sauf cas très particulier une validation de formulaire ça représente rien du tout en terme de charge serveur.

un formulaire de 16 champs numériques peut être l'objet d'une attaque et du moment que l'attaquant peut touché au code js alors vaut mieux passé au php.

La validation js c'est juste du cosmétique pour rendre la vie plus simple à ton utilisateur.

là par exemple pour lui indiqué que le champs est vide mais sa n’empêche d'ajouter un deuxième contrôle pour vérifier ce qui vient du formulaire.

@ Bovino:

la vérification côté client (JavaScript) n'a rien à voir avec la sécurité

si je met un contrôle en js pour vérifier le contenu d'un champs et l'attaquant change le code qui est aisément accessible , là sa serai du

la vérification côté serveur (PHP) sert d'abord à vérifier le format des données reçues ;

oui ça c'est compréhensible. merci

ce que je pense c'est mon avis:
tout ce qui relève de la sécurité et de contrôle serait pour le php.
tout ce qui est de l'ordre d'affichage de statistiques ou de données avec le js.

[grunk]

ce que je pense c'est mon avis:
tout ce qui relève de la sécurité et de contrôle serait pour le php.
tout ce qui est de l'ordre d'affichage de statistiques ou de données avec le js.

C'est ce que tout le monde te dis depuis le début ...

[Bovino]

ce que je pense c'est mon avis

C'est la moindre des choses !

[redoran]

oui mon ami ne te fâche pas , peut être que j'ai mal compris vos interventions.

[Seb33300]

un formulaire de 16 champs numériques peut être l'objet d'une attaque et du moment que l'attaquant peut touché au code js alors vaut mieux passé au php.

Oui, il faut faire le contrôle en php.
Mais tu peux également faire un pré-controle en javascript pour éviter à ton utilisateur de soumettre une page pour rien. ça lui fera gagner du temps. JS est quasi instantané alors que ton serveur lui si il est en période de forte affluence pourra mettre un peu plus de temps a rechercher une page complète.
Comme dit déjà plusieurs fois : c'est du confort.

[redoran]

Et bien merci a vous
Seb ta bien clôturé le post
merci encore une fois Seb , grunck et Bovino