asp.net - net - razor pages que es
¿Por qué se utilizan los campos ocultos? (8)
Siempre he visto muchos campos ocultos utilizados en aplicaciones web. He trabajado con el código que está escrito para usar muchos campos ocultos y los valores de datos de los campos visibles enviados a ellos. Aunque no entiendo por qué se utilizan los campos ocultos. Casi siempre puedo pensar en maneras de resolver el mismo problema sin el uso de campos ocultos. ¿Cómo ayudan los campos ocultos en el diseño?
¿Puede alguien decirme cuál es exactamente la ventaja que ofrecen los campos ocultos? ¿Por qué se utilizan los campos ocultos?
Aquí hay una razón, una forma conveniente de pasar datos entre el código del cliente (javascript) y el servidor.
El uso más común que veo / uso es para las ID y otras cosas que realmente no necesitan estar en la página por alguna otra razón que no sea la necesaria en algún momento para enviarlas de vuelta al servidor.
-editar, debería haber incluido más detalle-
digamos, por ejemplo, que tiene algún objeto que desea actualizar: la interfaz de usuario devuelve una colección de valores y el servidor en ese momento puede o no saber "hey, este es un objeto del cliente", por lo que envía una solicitud al servidor y diga "hey, dame el ID 7" y ahora tienes el objeto de tu cliente tal como lo sabe el sistema. Las actualizaciones se aplican, se validan, lo que sea y ahora su interfaz de usuario obtiene el resultado completo.
Supongo que una buena excusa / argumento es usar linq. Intente actualizar un objeto en linq sin obtenerlo primero de la base de datos. No tiene una idea real de que sea algo de lo que pueda realizar un seguimiento hasta que obtenga el objeto completo.
Generalmente se utilizan para almacenar el estado a medida que avanza la interacción. Las cookies podrían usarse en su lugar, pero algunas personas las deshabilitan. También podría usar un solo campo oculto para apuntar al estado del lado del servidor, pero luego hay problemas de adherencia de sesión.
Hay muchos escenarios útiles.
Una es "almacenar" algunos datos en una página que no debe ingresar un usuario. Por ejemplo, almacene la ID de usuario cuando genere una página, luego este valor se enviará automáticamente con el formulario al servidor.
Otro escenario es la seguridad. Agregue un token oculto a la página y verifique su existencia en el servidor. Esto ayudará a identificar si se envió un formulario a través del navegador o por algún bot que acaba de publicarse en alguna URL de su sitio.
Los campos ocultos son la forma más sencilla, por eso se utilizan bastante.
Alternativas:
- almacenamiento de datos en una sesión del lado del servidor (con cookie de sessionid)
- almacenar datos en un servidor de transacciones (con el ID de transacción como un único campo oculto)
- utilizando la ruta de la URL en lugar de los parámetros de consulta de campos ocultos cuando corresponda
Preocupaciones principales:
- no se puede confiar en que el valor del campo oculto no se modifique de una página a otra (a diferencia del almacenamiento del lado del servidor)
- Big Data debe publicarse cada vez, puede ser un problema y no es posible para algunos datos (por ejemplo, imágenes cargadas)
Ventajas principales:
- no hay sesiones pegajosas que se derramen entre páginas y múltiples ventanas del navegador
- no es necesaria la limpieza del lado del servidor (para los datos caducados)
- accesible a los scripts del lado del cliente
Mantiene las cosas fuera de la URL (como en la cadena de consulta) por lo que mantiene eso limpio. También mantiene las cosas fuera de la sesión que no necesariamente tienen que estar allí.
Aparte de eso, no puedo pensar en muchos otros beneficios.
Si está utilizando un campo oculto en el formulario, está aumentando la carga de la forma al incluir un nuevo control.
Si no hay necesidad de tomar un campo oculto, no debe hacerlo porque no es adecuado en las bases de seguridad. El uso de campos ocultos no entra dentro de la buena programación. Porque también afecta el rendimiento de la aplicación.
Supongamos que desea editar un objeto. Ahora es útil colocar la ID en un campo oculto. Por supuesto, nunca debe confiar en ese valor (es decir, asegurarse de que el usuario tenga los derechos adecuados al insert / update ).
Aún así, esta es una solución muy conveniente. Mostrar el ID en un campo visible (por ejemplo, cuadro de texto de solo lectura) es posible, pero es irritante para el usuario.
Almacenar el ID en una sesión / cookie es prohibitivo, ya que no permite múltiples ventanas de edición abiertas al mismo tiempo e impone restricciones de duración (el tiempo de espera de la sesión lleva a una operación de edición defectuosa, muy molesto).
El uso de la URL es posible, pero rompe las reglas de diseño, es decir, usa POST cuando se modifican los datos. Además, como es visible para el usuario, crea URL más feas.