interdire caractère spéciaux
Bonjour,
Pour mon formulaire d'inscription des clients, je souhaiterais interdire tout caractère spéciaux tel que : &~"#'{([-|`_\^@)]°}=+$£¤^¨ù%*µ!§+:/;.,?<> pour les champs nom, prénom....
Je suis complétement bloqué donc si quelqu'un pourrait m'aider??
Merci d'avance.
le seul moyen c'est en JS, le problème c'est que quelqu'un de mal intentionné aura vite fait de contourner ceci, si c'est pour stocker dans une base de données il faudra utiliser htmlspecialchars
Bonsoir,
en javascript il suffit de tester si le caractère frappé est dans la liste de caractères interdits (par le code document.onkeypress : tu trouveras des exemples)
--> coeos je ne sens pas le risque car il faudrait que la personne modifie le code, c'est vrai si le test controle une valeur que tu vois dans le code mais là ce n'est pas le cas , je crois
Modifier le code ou tout simplement désactiver le JS, comme 10% des gens le font
Bonjour,
comment peux tu modifier un code qui est sur un serveur ?
pour les personnes qui désactivent c'est dommage pour eux de perdre de la dynamique dans les fenêtres et il faut leur signaler qu'il l'active sinon la page est pauvre en utilisation (beaucoup de sites utilisent javascript heureusement)
il faut leur signaler qu'il l'active sinon la page est pauvre en utilisation (beaucoup de sites utilisent javascript heureusement)
certains utilisateurs ne peuvent pas l'activer !...
Bonjour,
comment peux tu modifier un code qui est sur un serveur ?Modifier le code, en ce qui concerne le javascript, c'est très facile après le chargement d'une page.
On peut absolument tout faire, recoder les fonctions, modifier les variables, en ajouter, etc. Et ainsi modeler totalement le comportement de n'importe quelle page, avec plus ou moins tous les navigateurs récents.
La notion clef c'est que le javascript est exécuté chez le client, pas qu'il est - certes - stocké sur le serveur. Par conséquent, il ne doit apporter que confort et ergonomie. En aucun cas il ne doit être employé comme solution *exclusive* de validation de saisie utilisateur, ou autres contrôles en tous genres.
La vérification côté serveur est donc indispensable pour garantir une sécurité optimale. C'est en revanche une très bonne chose de l'implémenter aussi en javascript, pour agrémenter la navigation de l'internaute.
En l'occurance, voici une implémentation grossière pour interdire certains caractères dans des champs <input> :
<input name="prenom" type="text" toto="this.value=this.value.replace(/[&~#'{[\-|`_\\^@)\]°}=+$£¤¨ù%*µ!§:/;\.,\?<>]/ig, '');" />
(Avec "toto" l'évènement "onkeyup" qui pour une raison étrange m'empèche d'envoyer mon post quand placé ci-dessus.)
Vu la liste à rallonge de caractères interdits, peut-être aurait-il fallu inverser le raisonnement et lister les caractères autorisés... C'est juste une suggestion :
<input name="prenom" type="text" toto="this.value=this.value.replace(/[^a-zA-Z0-9]/ig, '');" />
(Avec toujours le même évènement "onkeyup" en lieu et place de "toto".)
N'oublie pas de faire la même chose côté serveur !
Bonjour,
je ne veux pas trop "troller" mais quel intérêt de modifier le code javascript reçu sur le poste client sachant que la prochaine fois le même code initial sera renvoyé (si tu peux m"expliquer comment tu réalises cela).
La vérification faite par le serveur est couteuse car elle nécessite un aller retour vers le serveur.
Enfin la non utilisation du javascript interdit Ajax qui est quand même un outil intéressant. A+
Cela n'a rien d'un troll, tu fais bien de poser la question.
Je vais illustrer par un exemple : mettons que tu développes une e-boutique avec caddie & interface de checkout, etc.
Si tu fais tous tes contrôles et tes calculs exclusivement en javascript, alors le client est notamment en mesure de modifier le montant. C'est comme cela qu'on voit de grosses commandes arrivées avec des montants à payer de 0 euro, ou même des montants négatifs.
C'est la même réflexion pour le problème de davidblouin.
S'il fait ses contrôles de caractères interdits en javascript sans revalidation côté serveur, il n'y a absolument aucune garantie que ces contrôles soient effectués correctement car le client est maître du code javascript qui s'exécute chez lui.
Attention, qu'on se comprenne bien, le javascript est un très bon outil, et est totalement complémentaire avec des contrôles côté serveur. Il faut juste se rappeler qu'il n'est qu'un outil de confort facultatif.
La vérification faite par le serveur est couteuse car elle nécessite un aller retour vers le serveur.Oui et non. Elle nécessite un aller-retour vers le serveur, certes, mais pas un aller-retour supplémentaire par rapport au traitement côté client. En effet, l'information passe de toute façon à un moment donné par le serveur.
Ceci-dit, effectivement, si l'information n'est pas jugée valide par le serveur, alors un aller-retour supplémentaire a lieu pour prévenir le client. Mais dans 90% des cas, nos contrôles en javascript chez le client auront fait ce travail correctement !
Ce n'est pas pour autant qu'il faut négliger les 10 autres pourcents. Il en va de la sécurité de ton site web.
Enfin la non utilisation du javascript interdit Ajax qui est quand même un outil intéressant. A+C'est la frustration classique et très compréhensible du développeur qui n'admet pas que tous les clients ne soient pas intéressés par les fonctionnalités "fancy" proposées sur son site web.
Malheureusement c'est un fait, beaucoup de gens ne s'intéressent qu'au contenu brut, à la substantifique moelle. :-)
