¿Validar formularios en JavaScript o Php?

[chico_bds]

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:

1. QUe los campos no esten vacios.
2. que no me pacen espacios innecesarios.
3. Validar que un campo que recoge numero no inserten letras.

Ahora bien la validacion más importante.... mi opnion vale... es le del servidor, ya que es mas dificil pasarle por encima.

1. Comprobar que no se pasen datos con comillas ni nada de eso... para evitar inyecciones sql. (digamos que pasemos palabras claves para hacer una busqueda)

addslashes(trim(($palabras_claves)))

1. En caso de que vayamos ingresar datos a la bd, entonces no nos sirve la funcion de arriba... Ahora debemos verificar a travez de patrones... yo recomiendo eregi (mi humilde recomencacion..).

eregi("^[a-zA-Z ]*$", $nombre) or $nombre == "")

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

[[kayetano]]

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.

[semptrion]

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.

[lucasarts_18]

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.

[semptrion]

Empezado por lucasarts_18

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.

Entonces es una aplicación web. La diferencia radicará en que no serán formularios oportunistas y que deberemos tener mucho más cuidado en lo que traficamos.

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