Comparar campos de contraseña

alexsaiz · #1 (**permalink**) 15/08/2006, 16:44

Hola a todos!

¿Cómo es posible comparar en un formulario de registro el campo CONTRASEÑA y CONFIRMACION DE CONTRASEÑA para que en el caso de que no sean iguales retorne un mensaje de error al usuario diciendo que lo revise?

Muchas gracias por adelantado.
Un cordial saludo,
ALEJANDRO PEREZ

SaToNiO · #2 (**permalink**) 15/08/2006, 16:45

if ($_POST["campo1"]!=$_POST["campo2"]) {
echo "La contraseña no coincide con su confirmación.";
}

alexsaiz · #3 (**permalink**) 15/08/2006, 16:46

Muchas gracias por la veloz respuesta!

sofway · #4 (**permalink**) 15/08/2006, 18:02

Este tipo de validación sería mejor hacerla desde el lado cliente, osea utilizando JavaScript. De la manera que lo propones, el formulario tiene que enviarse para que despues tenga que cargar nuevamente y decir que no fué valido, lo que normalmente significa volver a llenar todo el formulario.

alexsaiz · #5 (**permalink**) 15/08/2006, 18:08

Ofrece más usabilidad para el usuario si se realiza en PHP. Y los campos en el formulario se pueden conservar, por ejemplo, de la siguiente manera:

Código PHP:

 
<input name="username" type="text" class="inputbox" id="username" value="<?if(isset($_POST['username'])) echo $_POST['username']?>" size="15" maxlength="15" />

No obstante, para gustos sobre usabilidad, colores.

Un saludo,
Alejandro.

sofway · #6 (**permalink**) 15/08/2006, 18:42

Alejandro me podrías explicar que quieres decir con ofrece más usabilidad para el usuario si se hace con php?.

Es bastante cierto que existen muchas maneras de lograr persistencia en los datos de un formulario a la hora de recargarlo, pero es ahí donde está el problema.. RECARGARLO, este tipo de validaciones al hacerlas con JavaScript ahorran una petición al servidor liberandole mucha parte del trabajo, y a la vez incomodas menos al usuario al hacerlo esperar menos tiempo en su registro.

alexsaiz · #7 (**permalink**) 15/08/2006, 18:45

Con PHP puedes indicar exactamente donde está el problema en el formulario, con JAVASCRIPT solo describes el problema. También puedes dar más información.

Además hay todavia usuarios que no disponen de JAVASCRIPT activado en su navegador por temas de seguridad, por lo que el usuario podría irse de la web si no puede registrarse.

Es decir, las ventajas de hacerlo en código dinámico son mucho mayores.

Un saludo,
Alejandro.

sofway · #8 (**permalink**) 15/08/2006, 18:56

alexsaiz: Con JavaScript es totalmente posible ubicar el problema en el formulario, y la verdad me parece bastante dificil dar con usuarios que no tengan activado JavaScript en su navegador pues desde hace varias versiones en prácticamente todos los navegadores, viene activado por defecto al concluir que JavaScript no presenta ningun problema en cuanto a seguridad.

Sería bueno escuchar mas puntos de vista sobre este tema.

Alguien que nos aporte???????

alexsaiz · #9 (**permalink**) 15/08/2006, 19:00

Perdona por mi ignorancia si así se puede. Lo que está muy de moda es utilizar AJAX, que tengo entendido que es Javascript dinámico.

Sofway muchas gracias por tu feedback.

rumo · #10 (**permalink**) 15/08/2006, 20:10

yo ocuparia js para ese tipo de validacion, como dice sofway ahorra el recargar la pagina de manera innecesaria y es mas rapido.

Cluster · #11 (**permalink**) 15/08/2006, 20:20

Cita:

Iniciado por alexsaiz

Perdona por mi ignorancia si así se puede. Lo que está muy de moda es utilizar AJAX, que tengo entendido que es Javascript dinámico.

Sofway muchas gracias por tu feedback.

Javascript ya es "dinàmico"

Ajax es la unión de javascript + un lenguaje del lado del servidor (PHP o el que gustes) con una llamada "asincrona" de datos entre el "cliente y el servidor" .. evitando en este caso la recarga de página completa .. viajando "sólo" los datos que usamos y no toda la "página" ...

Un saludo,

Cluster · #12 (**permalink**) 15/08/2006, 20:23

Cita:

Iniciado por rumo

yo ocuparia js para ese tipo de validacion, como dice sofway ahorra el recargar la pagina de manera innecesaria y es mas rapido.

No obstante .. -SIEMPRE- y por seguridad hay que volver a validar en el servidor (en PHP).

Si uno implementan validaciones es por algo: NO quieres que por ningùn motivo ese dato "pase" sin validación .. y si atendemos lo simple que es pasar por validaciones javascirpt y atacar directo el script PHP de proceso que registra esos datos .. es necesario siempre validar en PHP como seguridad.

No confundir "usabilidad" con "seguridad" .. Javascirpt aporta "usabilidad" .. y la "seguridad" en última instancia siempre la va a aportar PHP o el lenguaje del lado del servidor que se use.

Ahora .. si quieren combinarlo todo esto y usar "AJAX" .. no es mala opción: segura y usable (sin recarga de página como dato a destacar)

Un saludo,

Cluster · #13 (**permalink**) 15/08/2006, 20:29

Cita:

Iniciado por sofway

alexsaiz: Con JavaScript es totalmente posible ubicar el problema en el formulario, y la verdad me parece bastante dificil dar con usuarios que no tengan activado JavaScript en su navegador pues desde hace varias versiones en prácticamente todos los navegadores, viene activado por defecto al concluir que JavaScript no presenta ningun problema en cuanto a seguridad.

Sería bueno escuchar mas puntos de vista sobre este tema.

Alguien que nos aporte???????

Te invito a realizar una sencilla prueba.

1)Toma un formulario de cualquier web que valide sus datos con javascript.
2)Copia el código de esa pàgina a tu PC .. editala y quitale las validaciones javascript.
3) Toma el "action" de ese formulario y apunta ahí el URL completo donde está el script de proceso: http://www.nose.tal/formulario_procesa.php

Ahora .. ejecuta esa pàgina que tinenes en tu PC con tu navegador .. Introduce datos erroneos .. Ya te estás saltando la validaciòn javascirpt (tal cual si desactivas javascript en tu navegador) .. lo más "interesante" de esta prueba es comprobar que puedes "atacar" a tu script PHP de proceso en forma "remota" asì de simple ..

Por eso es tan necesario validaciones de "seguridad" en PHP .. no sòlo de los datos que se ingresan sino de -qué- formulario los produce. Esto es un grado màs de seguridad a implementar. Se suele solventar fácilmente con sesiones, creas una en el formulario y verificas su existencia en el script de proceso .. si no existe ya sabes que te están "introduciendo" datos -no desde tú formulario- ...

Un saludo,

alexsaiz · #14 (**permalink**) 15/08/2006, 22:13

Fantástica aclaración Cluster. Muchas gracias.

sofway · #15 (**permalink**) 16/08/2006, 09:01

Cluster tiene toda la razón, y es una táctica muy utilizada, en algunos casos considerada dentro de los ataques de DoS cuando se ataca el action del formulario con un sencillo loop. El punto a analizar entonces es, cuando es totalmente necesario hacer la doble validación??, depende de lo delicado de la información que contenga el formulario.

"La seguridad es inversamente proporcional a la funcionalidad", si hacemos validación en cliente y servidor para cada uno de nuestros formularios, pues tendremos un sitio muy "seguro", pero bastante pesado si estamos hablando de un buen nivel de concurrencia.

Me atrevería a decir que la doble validación aplicaría para un 10 % de los formularios de un sitio. (sin generalizar obviamente)

Saludos