Formulario Complicado

qazbeto · #1 (**permalink**) 10/03/2003, 03:56

Hola, aunque no se mucho de Php, pues me defiendo
lo malo es que me pidieron que haga un formulario que contenga:
Nombre
e-mail
Direccion
Telefono.
un comentario o tu duda.
y por si fuera poco

, me pidieron que si el telefono es mal llenado, recuerde eso al usuario, es decir que si lleno el telefono 1234567, esta bien, pero si lleno123467, que me regrese, o que me diga dato incorrecto, igual si es mas de 7 digitos.
Suena imposible y dificil, pero espero que alguien me de un link para eso porfa.
si eso del telefono es imposible, bueno que solo sea los anterior

NeBeRuS · #2 (**permalink**) 10/03/2003, 05:11

Imposible y dificl? si es de lo más básico...

a ver, si dices q sabes php, y luego dices q eso te suena imposible...

no se si sabrás como pasarle el formulario a php, la verdad...

en todo caso, es simplemente comprobar q solo metan numeros en el campo telefono (mirate los posts sobre "solo letrras y numeros" y "expresiones regulares" de hace unos dias.

Y luego, medir la longitud del campo.

P.D, tampoco seria complicado verificar q es un telefono válido de X pais.

P.P.D, funciones necesarias: ereg/eregi y strlen.

Cluster · #3 (**permalink**) 10/03/2003, 08:03

Hechandole un vistazo al manual de php encontraras funciones como:

is_numeric() .. para comprobar si un "dato" es numerico ..

El resto lo puedes implementar con Expresiones regulares como te comentó NeBeBus en esas funciones ereg() y afines (tambien están las preg_??? ..)

Solo decirte que las expresiones regulares NO son propias de PHP (por ende no busques mucha explicación sobre este tema en el manual de PHP oficial o en alguno de PHP ..)

Te dejo un manual sobre expresiones regulares:
http://www.ignside.net/man/php/regex.php

Un saludo,

josgat · #4 (**permalink**) 10/03/2003, 12:52

La forma más correcta de hacerlo mediante php es como te han mostrado anteriornete otros compañeros, pero personalmente creo que ese tipo de comprobaciones es mucho más apropiado hacerlas con javascript ya que de esta forma detectarás los errores antes de enviar el formulario. Así que si decides hacerlo en javascript pasate por el foro vecino dedicado a ello

.

ADEU

NeBeRuS · #5 (**permalink**) 10/03/2003, 12:56

la forma correcta de verificar los datos a insertar en el servidor, es en el propio servidor.

js sobra. y mas a la hora de verificar datos a insertar en una db, js se ejecuta en la makina cliente, por lo tanto, es "facilmente" modificable/"hackeable".

si, soi paranoico.

pero toma nota de esto, si vas a insertar algo en el servidor, primero se comprueba en el servidor, aunq decidas verificarlo en java.

josgat · #6 (**permalink**) 10/03/2003, 13:01

jeje, php forever. Estoy de acuerdo contigo en cuanto a seguridad se refiere ya que php se ejecuta en el servidor, pero sigo pensando que para determinados formularios es mejor (más rápido al menos

) hacerlo con js. Yo tb soy amante del php pero el js tiene sus ventajas. jeje

ADEU

Cluster · #7 (**permalink**) 10/03/2003, 14:15

Lo que manda es la validación del servidor ... Si quieres ahorrarte unos bytes q suben y bajan a tu servidor puedes usar ADEMAS de la INDISPENSABLE verificación en el servidor .. algo ej Javascript.

Yo por ejemplo de fomularios valido en javascript SOLO cosas básicas como por ejemplo q tengan valor los campos que requiero y poco mas ..

Y por supuesto SIEMPRE valido todos los datos en el servidor.

Un saludo,

sci-fi · #8 (**permalink**) 10/03/2003, 17:35

sí creo también que lo ideal sería, utilizar ambos para validar, javascript y php. porque javascript, excepto los usuarios que saben como desactivarla, la mayoría de los usuarios no saben cómo, y es beneficioso tanto para el navegante como para uno: al chequear del lado del cliente, se evita procesamiento del lado del servidor, y el navegante no tiene que esperar lo que se demora y la recarga de la página. Y validar del lado del servidor, que hoy en día es mucho mejor hacerlo con las expresiones regulares, éstas llevan tiempo, porque trabajan con comparación y búsqueda de texto, etc...

de todas maneras js no puede reemplazar a php o lo que se use en el server. Javascript solamente es un refuerzo de seguridad por un lado, y una mejora de interfaz para el cliente, solamente. Para evitar ataques, los que pueden hacer ataques saben como librarse de js fácilmente, por eso hay que chequear sí o sí del lado del servidor... lo único que, hacer los dos chequeos, se puede reutilizar algo de código, pero siempre es mucho más trabajo... en fin

ah también hay algo muy bueno que se puede utilizar en los formularios HTML. A todos los campos de texto (creo que a excepción de las <textarea>), se les puede poner un atributo de máximo de tantos caracteres, maxlength:

<input type="text" name="nombre" maxlength="8">

En este campo no se pueden escribir más de 8 caracteres, el navegador no lo permitirá. Creo que es buenísimo porque hasta ahora no sé de ninguna forma en que nadie pueda evitar este límite, ya que lo establece el navegador y es imposible agregar caracteres demás...

saludos

Cluster · #9 (**permalink**) 11/03/2003, 08:25

Cita:

Y validar del lado del servidor, que hoy en día es mucho mejor hacerlo con las expresiones regulares, éstas llevan tiempo, porque trabajan con comparación y búsqueda de texto, etc...

En javascript tambien puedes emplear expresiones regulares .. Fijate:
http://www.elcodigo.net/tutoriales/j...avanzado5.html

Las expresiones regulares no son propias de PHP .. Pero PHP por ejemplo como muchos otros lenguajes te ponen a tu disposición "funciones" o "métodos" para usarlas.

Un saludo,

NeBeRuS · #10 (**permalink**) 11/03/2003, 09:09

Cita:

Mensaje Original por sci-fi

ah también hay algo muy bueno que se puede utilizar en los formularios HTML. A todos los campos de texto (creo que a excepción de las <textarea>), se les puede poner un atributo de máximo de tantos caracteres, maxlength:

<input type="text" name="nombre" maxlength="8">

En este campo no se pueden escribir más de 8 caracteres, el navegador no lo permitirá. Creo que es buenísimo porque hasta ahora no sé de ninguna forma en que nadie pueda evitar este límite, ya que lo establece el navegador y es imposible agregar caracteres demás...

saludos [/B]

pues eso tb se puede burlar facilmente ;P

sci-fi · #11 (**permalink**) 11/03/2003, 10:03

hola neberus,

ok, pero como sería... sin que el que lo quiera burlar modifique el codigo fuente de la pagina, me refiero... me intriga saberlo ya que pensé que sería difícil desactivar algo así

Cluster · #12 (**permalink**) 11/03/2003, 10:48

Simplemente te haces un formulario en tu PC local ... y apuntas tu formulario a ese URL:

<form action="http://www.victima.tal/script_que_procesa_formulario.php"
method="post">
Mi formulario malicioso: <input type="text" name="nombre">
</form>

Como veras .. ejecutando este formulario desde mi PC (y navegador .. no hace falta ni servidor HTTP ni php ni nada .. es solo un formulario HTML) .. Me salto todo tu javascript y tag delimitadores q tengas ..

Un saludo,

sci-fi · #13 (**permalink**) 11/03/2003, 11:39

qué solución maquiavélica y efectiva... no se me había ocurrido... ya me estoy empezando a poner paranoico

gracias por el dato, saludos

sci-fi · #14 (**permalink**) 11/03/2003, 11:43

ahora que lo pienso... no se podrá chequear que el envío del formulario sea desde el mismo dominio del sitio...? con algún referer, o algo... alguna forma debe haber...

saludos

NeBeRuS · #15 (**permalink**) 11/03/2003, 12:20

Cita:

Mensaje Original por sci-fi
ahora que lo pienso... no se podrá chequear que el envío del formulario sea desde el mismo dominio del sitio...? con algún referer, o algo... alguna forma debe haber...

saludos

no solo se PUEDE sino q se DEBE hacer, de todos modos, yo no pensaba en lo q decia cluster, yo doy por sentado ese check ya, es de cajón.... al menos a mi entender, es algo básico en programación segura, y sobre como saltarse el limite, sin usar eso... pues, no suelo decir como joder las cosas, sino como arreglarlas ;)

Cluster · #16 (**permalink**) 11/03/2003, 12:41

NeBeBus .. ese "check" me parece q pocos lo usan ..

Bueno .. yo lo uso así simplemente en los scripts o mejor dicho .. porciones de código que tengan q procesar variables de un formulario/link .. :

Código PHP:

  <?

if (!@eregi($_SERVER['HTTP_HOST'],$_SERVER['HTTP_REFERER'])){

    header ("location: seguridad.php");

    exit;

}

?>

Un saludo, ..

sci-fi · #17 (**permalink**) 11/03/2003, 19:14

me parece muy bueno eso....

el único problema me parece que es que no todos los navegadores devuelven referer... Es decir, hay veces que ciertos navegadores no devuelven esa información al servidor, aunque deben ser pocos, hay un margen de error para los usuarios de esos navegadores. solamente quería notar esto, pero esa solución me parece muy buena... quizá se podría combinar con algún browser sniffing, y si estamos seguros de que obtenemos un referer, lo podemos implementar con más seguridad

saludos

qazbeto · #18 (**permalink**) 11/03/2003, 20:03

Tenian Razón, es mas facil de lo que crei.
eso diria un experto
pero como no es mi caso....

De Igual forma gracias por sus datos, aunque aun no logro nada, creo que intentando lo haré. y claro, gracias a sus consejos.

sci-fi · #19 (**permalink**) 11/03/2003, 21:04

hola,

para chequear que solo sea numerico y de no mas de 7 caracteres o dígitos, del lado del server con php:

Código PHP:

  if (ereg("^[0-9]{7}$", $var_post)) {

// solo 7 digitos es true

$var_post seria la variable que contiene los datos enviados por el usuario en ese campo

en javascript se puede hacer algo análogo con expresiones reg., suponiendo que el campo de llama "tel", harías algo así para acceder a lo que escribio el usuario....

Código:

var campo = document.forms['nombre_de_form'].tel.value;
// o bien si hay un solo form
var campo = document.forms[0].tel.value;

pero javascript se haría bastante largo, por los eventos, etc, si necesitas saberlo te lo digo en otro post

saludos...

Cluster · #20 (**permalink**) 12/03/2003, 08:58

Cita:

Mensaje Original por sci-fi
me parece muy bueno eso....

el único problema me parece que es que no todos los navegadores devuelven referer... Es decir, hay veces que ciertos navegadores no devuelven esa información al servidor, aunque deben ser pocos, hay un margen de error para los usuarios de esos navegadores. solamente quería notar esto, pero esa solución me parece muy buena... quizá se podría combinar con algún browser sniffing, y si estamos seguros de que obtenemos un referer, lo podemos implementar con más seguridad

saludos

Ese es un método "a lo PHP" .. de igual forma puedes hacerte algo si tienes control del servidor o posibilidad al menos de usar .htaccess (en Apache) como por ejemplo limitar el acceso a solo tu Host . (con los allow from IP .. y deny from all .. y directivas afines)

Un saludo,

NeBeRuS · #21 (**permalink**) 12/03/2003, 09:09

hay varias formas de hacerlo, pero todo es vulnerable, tenerlo en cuenta, el referer tb se puede trucar.

formas efectivas, a mi ver (aparte de los checks q ya se han dicho).

- Usar variables de sesion (el form no va a ser la primera pagina, por lo tanto, ya habra visitado otras paginas, y puedes meter un switch con una variable de sesion).

- Limitar el número de envios por IP.

- Pedir q introduzca una clave q aparece en un archivo grafico. Esto es demasiado paranoico, lo se, pero bueno, io lo uso para las altas en las webs.

en cualkier caso, tb puedes hacer un $textofinal=$textointroducido."mensajito enviado desde formulario en la pagina web tal, por user con la ip tal, y diciendo q si le han enviado spam lo notifique";

Y confiar en la gente xD

sci-fi · #22 (**permalink**) 12/03/2003, 16:48

están muy buenas esas medidas de seguridad...

gracias Cluster por ese código, me sirvió mucho... no sé si el referer es siempre creado por PHP -si la var $_SERVER['HTTP_REFERER'] siempre está aunque sea null- pero lo que se puede hacer es chequear que la variable no está vacía, y si no está, aplicarlo sin miedo a margen de error. creo que es importante por un lado la seguridad pero también reducir el margen de error, el costo, por ejemplo, que no haya errores para los navegantes. Por ejemplo, sería muy muy difícil que un navegante entre al form viniendo de otro sitio (sin embargo no es *imposible*; si, por ejemplo, se dispone a llenar el form, luego se acuerda de una cosa que tiene que consultar en otra página para poder rellenar el form, abre el historial y va, luego vuelve a la nuestra. O tal vez utilizando la barra de Google o de Yahoo en el MSIE y después apretando back. yo muchas veces hago eso, no precisamente a la hora de llenar el form... se podría decir que es un margen de error muy muy ínfimo pero lo pongo como ejemplo de cosas que pueden resultar inesperadas y que siempre salen), pero si eso sucede se le requerirá llenar el campo nuevamente por el referer, y si eso está combinado con chequeo de IP... tendrá que esperar para poder reenviarlo... yo no digo que chequear eso esté demás, por el mismísimo contrario, son muy buenas medidas de seguridad y les agradezco los datos

... es solamente que me preocupa, ya que, los usuarios o al menos el promedio no sabe de estas cosas, y se pueden enojar con uno por estas cuestiones de seguridad en algún caso inesperado, al menos hay que poner cuidado a la hora de la interfaz del sitio y poner explicaciones amables, etc, etc... Con respecto al referer, los usuarios de Opera, creo que este navegador trae *por defecto* el no usar referer logging, si no que para activarlo el usuario tiene que ir a las opciones. Esta opción creo que no se puede cambiar en el MSIE, en Mozilla tengo que verlo todavía....

de todas maneras utilizando una combinación de esas opciones, y siempre teniendo en cuenta que ninguna es infalible: los números de IP pueden variar, no siempre son fijos, etc; creo que utilizar variables de sesión es muy bueno también...; se puede lograr una muy buena combinación...

saludos

Vengeurman · #23 (**permalink**) 10/08/2006, 02:13

No creo que para comprobar que uns imple campo contenga un determinado numero de digitos se necesite verificar en el servidor, la verdad... La loginación logicamente se comprueba en el servidor, pero por ejemplo comprobar que un mail tenga una estructura correcta, que el telefono tenga 9 cifras o que los campos no estén vacios... no necesitas seguridad... y realmente comprobarlo en el server es ua verdadera tonteria. Sobretodo cuando hoy en dia Javascript es 100% W3C, o casi por completo.

djreficul · #24 (**permalink**) 10/08/2006, 02:37

Cita:

Iniciado por Vengeurman

No creo que para comprobar que uns imple campo contenga un determinado numero de digitos se necesite verificar en el servidor, la verdad... La loginación logicamente se comprueba en el servidor, pero por ejemplo comprobar que un mail tenga una estructura correcta, que el telefono tenga 9 cifras o que los campos no estén vacios... no necesitas seguridad... y realmente comprobarlo en el server es ua verdadera tonteria. Sobretodo cuando hoy en dia Javascript es 100% W3C, o casi por completo.

¿Crees q comprobando con Javascript ya estás seguro del todo? Me he saltado sistemas de comprobación javascript en el trabajo usando scripts en PHP sólo para demostrar lo vulnerable q es un sistema cuando no usa sesiones, no comprueba información en el servidor y otras kosillas más.

SIEMPRE hay q comprobar la información q se recoge en el servidor si no queremos obtener resultados desastrosos.

Saludos.

Cluster · #25 (**permalink**) 10/08/2006, 06:40

Cita:

Iniciado por Vengeurman

No creo que para comprobar que uns imple campo contenga un determinado numero de digitos se necesite verificar en el servidor, la verdad... La loginación logicamente se comprueba en el servidor, pero por ejemplo comprobar que un mail tenga una estructura correcta, que el telefono tenga 9 cifras o que los campos no estén vacios... no necesitas seguridad... y realmente comprobarlo en el server es ua verdadera tonteria. Sobretodo cuando hoy en dia Javascript es 100% W3C, o casi por completo.

Creo que estás confudiendo lo que significa "usabilidad" de un formulario a la hora de realizar validaciones y no tener que "recargar la página" (con el consumo de trasnferencia que eso implica entre otras cosas) con lo que realmente es "SEGURIDAD" ..

No entiendo bajo tu punto de vista para que entoces "validas" del lado del cliente (con Javasript) .. pero luego no haces nada en el "lado del servidor" y sabiendo que -sencillamente- puedes atacar tu script de proceso directamente como en este mismo mensaje se ha demostrado.

En ese caso NO valides nada .. y "confia" en lo que tus usuarios ingresen por error o malintencionalmente.

No sé si estás al tanto de problemas de seguridad como "SQL inyection" o "Cross site-scripting" entre otras cosas .. (En las FAQ's de este foro tienes información al respecto).

Deberías pensar un poco más lo que estás comentando ..

Un saludo,

janda · #26 (**permalink**) 20/02/2007, 20:55

muy bueno todo lo escrito, felicitacioens porq la verdad, apenas estoy aprendiendo a hacer formularios, y pensaba validar algunas cosas, pero he visto el gran problema del spamm, ahora entiendo como funciona y creo q necesito revisar mas cosas de seguridad...no se mucho de sesiones...he tratado de usarlas pero no he podido...no se si toca activarlas tan solo en el codigo php o si toca hacer algo mas.... nuevamente muchas gracias....