¿Propósito original de <input type = “hidden”>? [cerrado]


101

Tengo curiosidad sobre el propósito original de la <input type="hidden">etiqueta.

Hoy en día, se usa a menudo junto con JavaScript para almacenar variables que se envían al servidor y cosas así.

Por lo tanto, <input type="hidden">existía antes de JavaScript, entonces, ¿cuál era su propósito original? Solo puedo imaginarme enviar un valor desde el servidor al cliente que se envía (sin cambios) para mantener una especie de estado. ¿O me sale algo mal en el historial y <input type="hidden">siempre se suponía que debía usarse junto con JavaScript?

Si es posible, también proporcione referencias en sus respuestas.


3
Fuera de tema para SO, aunque mantener el estado también sería mi elección
Phil

De acuerdo, para permitir el seguimiento del estado precargado (por ejemplo, de un PK sustituto durante una edición) que se incluiría automáticamente en un formulario enviado POST / GET
StuartLC

1
Existir antes de JavaScript admite razones para tenerlos aún más (es decir, no resta valor a ninguna razón como parece implicar esta pregunta): no había JavaScript para "almacenar variables" o llamar a AJAX o stub en la entrada "no oculta" campos antes de enviar un formulario ... tampoco había CSS para otros trucos perversos, como ocultar una entrada de texto normal.
user2246674

Respuestas:


108

Solo puedo imaginarme enviar un valor desde el servidor al cliente que se envía (sin cambios) para mantener una especie de estado.

Precisamente. De hecho, todavía se usa para este propósito hoy porque HTTP como lo conocemos hoy sigue siendo, al menos fundamentalmente, un protocolo sin estado.

En realidad, este caso de uso se describió por primera vez en HTML 3.2 (me sorprende que HTML 2.0 no incluye tal descripción):

type=hidden
Estos campos no deben representarse y proporcionar un medio para que los servidores almacenen información de estado con un formulario. Esto se devolverá al servidor cuando se envíe el formulario, utilizando el par nombre / valor definido por los atributos correspondientes. Esta es una solución para la apatridia de HTTP. Otro enfoque es utilizar "cookies" HTTP.

<input type=hidden name=customerid value="c2415-345-8563">

Si bien vale la pena mencionar que HTML 3.2 se convirtió en una recomendación del W3C solo después del lanzamiento inicial de JavaScript, es seguro asumir que los campos ocultos casi siempre han tenido el mismo propósito.


Lo único que no me gusta de usar entradas 'ocultas' para almacenar datos es que esos datos pueden ser manipulados por los usuarios, concedido, probablemente solo alguien que entienda HTML y cómo modificarlo a través de herramientas de desarrollo, pero podría tener malas implicaciones en la base de datos si la modificación de esos valores corrompe otros datos (por ejemplo, si está almacenando la referencia de la clave principal y el usuario la cambia manualmente).
Brett84c

3
@ Brett84c: Es por eso que siempre debe validar su entrada y nunca confiar en el cliente;)
BoltClock

Exactamente, solo estaba lanzando eso para que los nuevos desarrolladores sean conscientes de los posibles peligros involucrados.
Brett84c

2
Nada acerca de esos peligros es específico de las entradas "ocultas"; cualquier cosa que se envíe al cliente puede manipularse antes de que vuelva. Las cookies o las alternativas basadas en JS son iguales.
FLHerne

10

Proporcionaré un ejemplo simple del mundo real del lado del servidor aquí, digamos si los registros están en bucle y cada registro tiene un formulario con un botón de eliminación y necesita eliminar un registro específico, así que aquí viene el hiddencampo en acción, de lo contrario, ganó ' Para obtener la referencia del registro a borrar en este caso, seráid

Por ejemplo

<?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
    }
?>

1
Buen ejemplo, excepto que el código real debe usar declaraciones preparadas u otra forma de manejar de forma segura la entrada SQL.
Matthew Flaschen

8

En resumen, el propósito original era crear un campo que se enviará con el envío del formulario. A veces, era necesario almacenar cierta información en un campo oculto (por ejemplo, la identificación del usuario) y enviarla con el envío del formulario.

De la especificación HTML del 22 de septiembre de 1995

Un elemento INPUT con 'TYPE = HIDDEN' representa un campo oculto. El usuario no interactúa con este campo; en cambio, el atributo VALUE especifica el valor del campo. Los atributos NAME y VALUE son obligatorios.


1
¿Podría dar más detalles sobre esa respuesta y / o dar alguna referencia a este comportamiento de enviar los campos ocultos después de enviar un formulario?
GitaarLAB

@GitaarLAB, di un ejemplo (ID de usuario) ... De todos modos, hay muchos ejemplos en web. Por ejemplo echoecho.com/htmlforms07.htm
Chuck Norris

1
Lo siento, para mí la línea: original purpose was to make a field which will be submitted *after* form's submites ambigua. Se puede interpretar como: 'después de que el formulario se realiza la publicación de sus datos, a continuación, se presentará el campo oculto (a un lugar misterioso)'. De ahí mi comentario anterior.
GitaarLAB

1
Lo entiendo :) Gracias por tu comentario, he editado mi respuesta. Fue simplemente un error ortográfico (aún no he alcanzado el nivel de gurú en inglés: D).
Chuck Norris

6

Los valores de los elementos del formulario, incluido type = 'hidden', se envían al servidor cuando se publica el formulario. tipo de entrada = los valores "ocultos" no son visibles en la página. Mantener los ID de usuario en campos ocultos, por ejemplo, es uno de los muchos usos.

SO utiliza un campo oculto para el clic de voto a favor.

<input value="16293741" name="postId" type="hidden">

Con este valor, la secuencia de comandos del lado del servidor puede almacenar el voto a favor.


¡Jaja, buen partido! Y cuando agrego una "x" al final del valor, se produce un error al votar a favor: D
Uooo

@Uooo Y puedes mostrarlo o cambiar directamente el valor. Puede cambiar el valor a una respuesta diferente. Luego puede hacer clic en el botón de voto a favor y se registra como un voto a favor para una respuesta diferente. ;)
Geoffrey Hale

5

Básicamente, los campos ocultos serán más útiles y ventajas de usar con el formulario de varios pasos. podemos usar campos ocultos para pasar la información de un paso al siguiente paso usando hidden y mantenerla reenviada hasta el paso final.

  1. Tokens CSRF.

La falsificación de solicitudes entre sitios es una vulnerabilidad de sitios web muy común. Exigir un token secreto y específico del usuario en todos los envíos de formularios evitará los ataques CSRF, ya que los sitios de ataque no pueden adivinar cuál es el token adecuado y cualquier envío de formularios que realicen en nombre del usuario siempre fallará.

  1. Guardar el estado en formularios de varias páginas.

Si necesita almacenar el paso en un formulario de varias páginas en el que se encuentra actualmente el usuario, utilice campos de entrada ocultos. El usuario no necesita ver esta información, así que ocúltela en un campo de entrada oculto.

Regla general: utilice el campo para almacenar cualquier cosa que el usuario no necesite ver, pero que desee enviar al servidor al enviar el formulario.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.