|
¿Validar formularios en JavaScript o Php?
Hola a todos:
Tengo una gran duda, ¿qué es mejor?, validar en JavaScript o Php, la idea es que quede la validación de formularios solo en un lugar, para no tener que hacer trabajo repetitivos, ¿según ustedes cual es la mejor opción?. Yo por otra parte opino que validar en php es mas costoso en tiempo ya que aparte de ver que los datos vienen correctos del formularios hay que procurar que en caso de error hay que mantener dichos datos en el formularios, por lo tanto se alarga la programación, en cambio con Javascript solo te preocupas de validar. Espero sus experiencias y opiniones... Gracias....:) |
Hola,
Ni la una ni la otra opción por separado, según mi humilde opinión. Pero me explicaré. Las validaciones en el lado del cliente (JavaScript) tienen la ventaja de que no se realizarán peticiones al Servidor si los datos de un formulario no cumplen ya con unas determinadas reglas. Por otro lado, supongo que no estará demás validar los datos del lado del Servidor, o lo que es lo mismo, no confiar del todo en lo que nos llega del cliente, aunque se suponga que el contenido ha sido previamente validado. Piensa en que yo puedo hacer un "HTTP POST" o "HTTP GET" desde Delphi, enviando ciertos datos... que tu JavaScript no va a validar, puesto que no estoy dentro del navegador "usual". Y ahora habría que ver si merece la pena implementar la validación en JavaScript, si no merece la pena, en fin... también creo que depende de la aplicación en concreto, empero, fíjate que estoy dejando como opcional la validación en JavaScript, pero doy por sentado que esta se llevará a cabo de todas formas en el Servidor. Vamos, digo yo. ¿Eh? A ver qué opinan los monstruos de esto. :) |
Enfatizando y/o complementando lo que dice David, yo siempre he pensado que deben hacerse ambas.
Por un lado, no es posible evitar la validación del lado del servidor. Éste no debe asumir nada acerca de lo que haya hecho el cliente porque el cliente puede alterar la validación o simplemente suprimirla. La validación en el cliente- en mi opinión -es meramente "ornamental"; tu sistema puede- y debe -prescindir de ella. Está únicamente para ayudar al usuario. Si hay alguna validación que pueda hacerse del lado del cliente, ayudas al usuario al ahorrar viajes al servidor para detectar que algo en los datos está mal, por ejemplo, el formato de algún campo. Pero, por lo dicho antes, tal validación deberá repetirse en el servidor. De todas formas, ayudar al usuario es algo muy importante, y por ello digo que es necesaria también la validación del lado del cliente, siempre que sea posible. Pero, igual que dec, esperemos a ver qué dicen los mounstruos. // Saludos |
Hola,
De acuerdo con Román. Únicamente creo que podría decirse que además de una cuestión puramente ornamental validar los datos vía JavaScript puede acaso evitar alguna que otra petición HTTP. Pienso en el más o menos típico formulario de entrada a una aplicación. Supongamos que el login de usuario tiene que tener más de cuatro caracteres para ser considerado válido: podemos evitar el envío del formulario si no se da esa circunstancia, advirtiendo al usuario de la misma, haciendo únicamente uso de JavaScript y evitando una petición HTTP. Oyes... una petición HTTP puede no significar mucho, pero, tacita a tacita... Y, por otro lado (y a eso iba antes con lo de que dependía de la aplicación, del formulario, etc.), digo que, por otro lado, hay peticiones HTTP y peticiones HTTP. No ha de ser lo mismo validar en el Servidor un campo de un formulario que todo el formulario. Pienso en la típica opción que se ve en algunos formularios de registro, que al lado de la casilla para escribir nuestro login de usuario, aparece otro botón o un enlace que dice algo como "Pincha aquí para comprobar si el login de usuario está disponible". Es algo para lo que necesitamos del Servidor, seguramente, pero, no necesitamos enviar todo el formulario para que al cabo el Servidor nos responda con un mensaje de error: "El login de usuario elegido ya está en uso, por favor, eliga otro"... lo cual puede ser tan contraproducente como general pueda ser un login de usuario. Probad a abrir una cuenta de correo en GMail y veréis lo que os digo: es complicado elegir un nombre de usuario, un login... porque ya hay escogidos un montón de ellos. El formulario de registro de Gmail (al menos la última vez que lo ví así era) cuenta con la opción que menciono: "Comprobar si el login de usuario está en uso". Para esto último el uso de "AJAX" es estupendo, claro está. :) |
Bueno, bueno....No recuerdo donde leí que un autor de un libro decía "No hay que abusar de javascript sino ser lo suficientemente inteligentemente para ver donde utilizarlo".
Con la cita anterior supongamos que el usuario tiene que hacer muchas tareas repetitivas tales como asignarles varios checkbox, entonces la opción seleccionar todo viene al pelo, por otra parte como dice roman "Está unicamente para ayudar al usuario", por lo tanto haré validaciones javascript, pero sola las más obvias, es decir ayudar al usuario, pero he decidido que el servidor debe validar todo por seguridad. Igual que ustedes esperando a ver lo que dice kayetano y otros gurus del tema....jeje :p |
Cita:
Cita:
Cita:
Veo que todos estamos de acuerdo, y la mención de Ajax para validar campos individuales es muy acertada. Eso sí, desafortuadamente, el sistema no puede depender de JS, el usuario puede deshabilitarlo y debemos arreglárnoslas sin él. // Saludos |
Validacion cliente servidor
Voy a darte unas sugerencias muy novatas vale!!
Como bien han dicho los compañeros del forum debes hacer la validacion desde javaScript para evitar peticiones al servidor, pero no solo esto tambien ayudar al usuario. Mira por ejemplo yo valido con javaScript lo siguiente:
Asumiendo por supuesto que hemos recogido los datos de formulario en la variable $nombre. Esta funcion evitaria la entrada de numeros o espacios en el nombre. Saludos y espero haberte servido de alguna ayuda. ------------------------------------------------------------------ url: http://www.crealotu.com |
Hola
Pues bien, después de todo lo dicho yo añado la siguiente opción: AJAX, o mejor dicho, validación en el servidor usando javascript. Hace algún tiempo empece un sistema de validación con AJAX, según se van rellenando los distintos datos del formulario se hace una comprobación en el servidor con AJAX, cada llamada al validador devuelve un código de autentificación, cuando se envia el formulario se comprueba que el código de validación existe y es correcto con lo que se evita el envío de formularios desde otra aplicación que no sea la nuestra. Por desgracia no llegue a poner en marcha el proyecto y se quedó como esperimental. Como ya se ha comentado la comprobación de datos en el servidor es lo más aconsejable y dejar el javascript simplemente para indicar al usuario como debe rellenar el formulario. |
Respecto de la validación
Estuve revisando los comentarios acerca de tu consulta y encuentro muy acertada la respuesta que te dio dec cuatro días atrás.
Lo que sucede es que en el lado del cliente, no se puede hablar de validación. Lo que quiero decir es que nosotros, al momento de programar no sabemos cual será el cliente. Puede ser un navegador (que es lo más frecuente) pero tambi;en pueden ser programas de exploración o de hacking. Como debes bien saber, cuando un cliente te hace una petición de grabación, ignoras por completo su identidad (porque puede ser un programa enmascarado) y que, si confiaste la validación a ese lado, pues ya te enchufaron alguna barbaridad. Un ejemplo de como enmascarar a un cliente publiqué en noviembre de 2003 en http://us2.php.net/manual/es/function.fsockopen.php [This is a very fast program for test a form or link (many times).] que es un programa que utiliza sockets para enmascararse en una solicitud sea POST o GET y que, cuando no se realiza validación del lado del servidor, permite hacer algo. (Cabe aclarar que el programa fue diseñado para testear sitios, aunque su uso a salido de ese contexto y ha sido utilizado por ejemplo, para votar en encuestas, deformando resultados de algunos sitios primitivos y en algunos casos, para pruebas de passwords, llenado "automático de formularios", etc.) Entonces, cuando el desarrollador se apoya en el cliente, se está apoyando en bruma: nada de nada. Todo es (o puede ser) ficticio del lado del cliente. Al fin de cuentas, lo único que conocemos es lo que el cliente nos informa que es. Y puede ser muchas cosas: puede ser un IE 5.0 o un mozilla; puede ser una cámara de video o puede ser un dispositivo para braile; puede ser un robot o puede ser un navegador de texto. Si es un browser (si tenemos la fortuna que no nos engañe y sea un browser de verdad) puede o no soportar el código javascript que hemos preparado cuidadosamente para "ayudar" al usuario y para que "no tenga que esperar tanto". Así, AJAX y otras "ideas" no dejan de ser buenas al momento de recibir información. Aunque incompletas por el tema de la diferencia entre los clientes, llegan a ser muy malas en tiempo de validación. Usen AJAX, AXE o lo que gusten. Sólo confíen en la validación del lado del servidor. Si no la tienen, prepárense a recibir basura o peor aún, a ver como destruyen la data del sitio. Y es que hay otra premisa (la primera fue: no confíes en el cliente) y es que no existen usuarios tontos o inexpertos en la internet. Tarde o temprano algún desesperado con suerte encontrará la forma de violar la validación del lado del cliente. Conclusión: validar del lado del servidor es la única opción. Validar del lado del cliente, es... tanto trabajo para nada, que quizá no valga la pena intentarlo. Ahora, la inteligencia del desarrollador radica en que debe hacer tan pocas consultas al servidor como le sea posible. Es decir, si es un formulario, deberá enviarlo una sola vez, y no partirlo en pequeños trocitos incrementales como si fuera un programación stand alone, es decir, donde tenemos toda la lógica de la aplicación residente en memoria. Así, quizá sea necesario que empecemos a pensar que hay algunas cosas que podemos "asumir" como por ejemplo el tema de los espacios en blanco o de si un texto debía ser introducido en mayúsculas haya sido introducido en minúsculas, o que le puso letras en vez de números, etc. Es decir, que hay algunas cosas que pasan con demasiada frecuencia como para saber cual es la acción que debemos tomas. Por ejemplo, si colocaron espacios antes del texto o después del texto, le aplicamos la función trim y asunto arreglado. Si el usuario puso minúsculas en vez de mayúsculas, pues convertimos el texto en mayúsculas. Y así así. Por esas macanas no fastidiamos al usuario ni utilizamos su canal para "avisarle" que "metió la pata" y que sus datos no se han grabado por ello. Es más, existen por lo menos dos niveles de error: alertas y errores. Los errores son los que impedirían que continúe el proceso de grabación, porque, por ejemplo se quiere colocar un texto en vez de una fecha; en cambio las alertas son las que permiten grabar, pero no terminar la tarea. Con lo que quedamos en que: - Se debe enviar el formulario una sola vez y con toda la información. - En caso de error en la validación: * Si existen acciones que se puedan tomar, se las toma (p.e. quitar espacios) * Si existe la posibilidad que el valor del campo perjudique la operación del sistema, se considera que es un error (no se graba y se informa) * Si no existe la posibilidad que el valor del campo perjudique la operación del sistema, se determinará alerta, que permitirá grabar los datos, pero no continuar con el siguiente paso (por ejemplo, terminar). - Un error se informa (y se informa que no han sido grabados los datos) - Una alerta se informa (y se informa que han sido grabados los datos, pero que no podrá continuar con la siguiente operación, si no corrige) - Una acción se informa (y se informa lo que se ha modificado) Esta mecánica de trabajo la utilizo cuando se trata de aplicaciones sobre la web. Es decir, en el caso de formularios oportunistas (por ejemplo los de suscripción que sólo se presentan una vez), la distinción entre error y alerta es prácticamente inexistente. Bueno. Y me alargué nomás. Espero que te sirva de algo lo indicado. Y todo esto, del lado del servidor. |
Muy buenos argumentos, agregó otro asunto, tambien hay que ver la situación del sistema,no es lo mismo un sistema web accedido via internet que uno accedido via intranet. :)
|
Muy cierto
Cita:
Además, conozco más problemas de seguridad en una intranet que en una internet, por que los usuarios tienen mucho más tiempo manipulando las aplicaciones y llegan a conocerlas a veces más que el propio desarrollador. En el caso de una Universidad que recibía inscripciones en línea, una estudiante de psicología me comentaba algo así como: "No podía inscribirme en tal materia, por lo que alguien me indicó que si llegaba al formulario donde seleccionaba materias, debía hacer back dos veces y luego fordward dos veces y ya me iba a aparecer la materia." Ante mi incredulidad (e ingenuidad) pasó a demostrarme que era así evidentemente. Un sistema de intranet cuya seguridad estaba basada en el cliente fue hackeado... er... por una estudiante de psicología. Entonces, prefiero tratar el Internet y la Intranet como similares, aplicando todo cuanto puedo y sé para protegerlas, sin diferenciarlas. Sobre todo en eso del maldito problema de validar formularios desde el lado del servidor. Saludos |
| La franja horaria es GMT +2. Ahora son las 08:33:36. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi