Je suis curieux de connaître le but initial de la balise <input type="hidden">
.
De nos jours, il est souvent utilisé avec JavaScript pour y stocker des variables qui sont envoyées au serveur et ainsi de suite.
Par conséquent, le <input type="hidden">
existait avant JavaScript, quel était donc son objectif initial? Je ne peux qu'imaginer que le serveur envoie au client une valeur (non modifiée) renvoyée pour conserver une sorte d'état. Ou est-ce que je me trompe dans l'histoire et que <input type="hidden">
était toujours supposé être utilisé avec JavaScript?
Si possible, veuillez également indiquer des références dans vos réponses.
Je peux seulement imaginer d'envoyer une valeur du serveur au client qui est (non modifiée) renvoyée pour maintenir une sorte d'état.
Précisément. En fait, il est encore utilisé à cette fin aujourd'hui, car HTTP, tel que nous le connaissons aujourd'hui, est toujours, du moins fondamentalement, un protocole sans état.
Ce cas d'utilisation a en fait été décrit pour la première fois dans HTML 3.2 (je suis surpris que HTML 2.0 n'inclue pas une telle description):
type=hidden
Ces champs ne doivent pas être rendus et fournissent aux serveurs un moyen de stocker des informations d'état avec un formulaire. Celui-ci sera renvoyé au serveur lors de l'envoi du formulaire, à l'aide de la paire nom/valeur définie par les attributs correspondants. C'est un moyen de contourner l'état sans état de HTTP. Une autre approche consiste à utiliser des "cookies" HTTP.<input type=hidden name=customerid value="c2415-345-8563">
Bien qu'il soit utile de mentionner que HTML 3.2 est devenu une recommandation du W3C uniquement après la version initiale de JavaScript, il est prudent de supposer que les champs cachés ont pratiquement toujours servi le même objectif .
Je vais donner un exemple simple du monde réel côté serveur ici, par exemple, si les enregistrements sont en boucle et que chaque enregistrement a un formulaire avec un bouton de suppression et que vous devez supprimer un enregistrement spécifique, voici le champ hidden
en action sinon vous n'obtiendrez pas la référence de l'enregistrement à supprimer dans ce cas, ce sera id
Par exemple
<?php
if(isset($_POST['delete_action'])) {
mysqli_query($connection, "DELETE FROM table_name
WHERE record_id = ".$_POST['row_to_be_deleted']);
//Here is where hidden field value is used
}
while(condition) {
?>
<span><?php echo 'Looped Record Name'; ?>
<form method="post">
<input type="hidden" name="row_to_be_deleted" value="<?php echo $record_id; ?>" />
<input type="submit" name="delete_action" />
</form>
<?php
}
?>
En bref, le but initial était de créer un champ qui sera soumis avec le formulaire de soumission. Parfois, il était nécessaire de stocker des informations dans un champ caché (par exemple, l'identifiant de l'utilisateur) et de les soumettre avec le formulaire de soumission.
D'après la spécification HTML du 22 septembre 1995
Un élément INPUT avec `TYPE = HIDDEN 'représente un champ caché. L'utilisateur n'interagit pas avec ce champ; à la place, l'attribut VALUE spécifie la valeur du champ. Les attributs NAME et VALUE sont requis.
Les valeurs des éléments de formulaire, y compris type = 'hidden', sont soumises au serveur lors de la publication du formulaire. type d'entrée = "caché" les valeurs ne sont pas visibles dans la page. Conserver les ID utilisateur dans les champs cachés, par exemple, est l’une des nombreuses utilisations.
SO utilise donc un champ caché pour le clic upvote.
<input value="16293741" name="postId" type="hidden">
En utilisant cette valeur, le script côté serveur peut stocker le vote positif.
les champs fondamentalement cachés seront plus utiles et les avantages à utiliser avec un formulaire multi-étapes. nous pouvons utiliser des champs cachés pour transmettre des informations d’étape à l’étape suivante à l’aide de hidden et conserver les transferts jusqu’à la fin.
Falsification de requêtes intersites est une vulnérabilité très répandue dans les sites Web. Le fait d'exiger un jeton secret spécifique à l'utilisateur dans toutes les soumissions de formulaire évitera les attaques CSRF, car les sites d'attaque ne peuvent pas deviner quel est le jeton approprié et toute soumission de formulaire qu'ils effectuent pour le compte de l'utilisateur échouera toujours.
Si vous devez enregistrer l'étape à laquelle l'utilisateur se trouve actuellement dans un formulaire comportant plusieurs pages, utilisez des champs de saisie masqués. L'utilisateur n'a pas besoin de voir cette information, alors masquez-la dans un champ de saisie masqué.
Règle générale: utilisez ce champ pour stocker tout ce que l'utilisateur n'a pas besoin de voir, mais que vous souhaitez envoyer au serveur lors de la soumission du formulaire.