Importance des champs cachés en html

[rodrigue daniel]

Salut je suis Rodrigue Daniel

En html, je souhaiterais savoir concrètement l'importance des champs cachés (<input type="hidden" />).
En effet j'ai suivi que certaines personnes l'utilisent pour stocker des constances au niveau formulaire.
Alors pourquoi utiliser une technique pareil pourtant on peut bien déclarer une constance en php ? En plus
en parlant de cacher, le code php n'est pas visible côté client ou alors cette technique de champs cachés n'est plus d'actualité.
Bref je souhaiterais un éclaircissement.

MERCI

[Anonyme77]

Je dirais que ça dépend des cas.
Il m'est arrivé que ce soit absolument nécessaire.

Par exemple, tu as un formulaire qui sert à faire de l'ajout ou de la modification d'une donnée.
Donc, quand tu reçois un post venant de cette page tu ne sais pas si c'est un ajout que tu dois faire dans la DB ou une modification d'un enregistrement. Un champs <input type="hidden" name"modify" value="true"/> peut t'aider à gérer ce genre de problèmes.

[rodrigue daniel]

Salut

Merci pour cette réponse : c'est vraiment concrèt.
Peut-on gérer cette situation uniquement en PHP?
Car j'ai lu quelque part qu'il y'avait des failles de ce genre qu'un pirate pouvais
exploiter ou alors ce n'est rien du tout.

MERCI

[Anonyme77]

Je dirais que c'est une faille si c'est mal utilisé.
Si tu fais passer des informations sensibles.

Je ne vois pas comment gérer la problématique uniquement en PHP.
Maintenant, si vous avez une solution, donnez la moi j'en serai heureux .

[rodrigue daniel]

Salut

C'est vrai, j'ai un peu pensé à ça, c'est vraiment difficile.
Bon, merci beaucoup.

[Back2back]

Certes il est possible de modifier la valeur du champ POST, mais si c'est bien protégé coté serveur, que tu vérifies biens qu'il y a deux cas possible, la modification ou l'ajout, tu devrais pas trop être embêté. La seule chose possible sera de dire que c'est un ajout alors qu'en faite il s'agit d'une modif, et inversement.

Du moins, avec mes connaissances, je vois rien d'autres.
Tout dépend de ton PHP derrière, mais si tu as que ces deux options, et que tu blindes si la variable est différente des deux pour retourner une erreur, tu devrais être tranquille.

[Anonyme77]

Au niveau des technologies web, je pense qu'il est indispensable de faire de la validation à la fois côté client et serveur.

Pensez bien que certain clients n'autorisent pas le javascript.
Donc pas de vérifications de ce côté.

Il y a également ceux qui forgent des requêtes pour tester la solidité d'un site.

Pensez donc toujours bien à vérifier les données envoyées par les clients dans ces deux côtés.
Comme disait toujours l'un de mes profs :
"Never trust user input".

[Invité]

Salut

Donc, quand tu reçois un post venant de cette page tu ne sais pas si c'est un ajout que tu dois faire dans la DB ou une modification d'un enregistrement. Un champs <input type="hidden" name"modify" value="true"/> peut t'aider à gérer ce genre de problèmes.

Le client je dois jamais être de près ou de loin en interaction avec la BDD.
Architecture trois tiers

Je ne vois pas comment gérer la problématique uniquement en PHP.
Maintenant, si vous avez une solution, donnez la moi j'en serai heureux .

je pense :

1 - tu récupères tes valeurs

2 - tu vérifies si une entrée existe ( sql COUNT)

3 :

Si une entrée existe

• c'est une modification.

Sinon

• c'est un enregistrement.

[Anonyme77]

Le client je dois jamais être de près ou de loin en interaction avec la BDD.

Je dois m'être mal exprimé Erenox.
Je parlais bien de recevoir une requête HTTP POST. Sur le serveur donc.
Puis de toute façon le code client n'a pas les capacités (les protocols ne sont pas implémentés en JS je pense) de communiquer avec le serveur.
Je suis aussi tout à fait d'accord avec toi sur le fait qu'il ne doit pas le faire.

...

je pense :

1 - tu récupères tes valeurs

2 - tu vérifies si une entrée existe ( sql COUNT)

3 :

Si une entrée existe

• c'est une modification.

Sinon

• c'est un enregistrement.

Cela suppose que ton identifiant est un champs dans ta page non ?

Si c'est un identifiant technique (un integer auto increment par exemple), il n'est pas forcément logique qu'il soit mis dans la page non ?
Puis dans ce même cas, une nouvelle entité n'a pas encore son identifiant.

[Invité]

Je parlais bien de recevoir une requête HTTP POST

Oui moi aussi.

Puis de toute façon le code client n'a pas les capacités (les protocols ne sont pas implémentés en JS je pense) de communiquer avec le serveur.

On est d'accord, mais dans ce cas, il a les capacités de modifier le fonctionnement de ton application via les données qu'il envoie depuis le formulaire alors qu'il ne devrais pas.

Cela suppose que ton identifiant est un champs dans ta page non ?

Si c'est un identifiant technique (un integer auto increment par exemple), il n'est pas forcément logique qu'il soit mis dans la page non ?
Puis dans ce même cas, une nouvelle entité n'a pas encore son identifiant.

Tu recupère toutes les valeurs du formulaire qui correspond aux données de l'utilisateur : (nom, prénom, pseudo,...).

Tu laisse la partie applicative faire le reste : (Authenticité, Verification, Chiffement, Generation UID, ...).Ainsi que les operation a faire sur la BDD

un champ du type hidden pour vérifier si une entrée est presente dans la BDD est au mieux inutile au pire dangereux.