Validar con php, Ajax, js, que es mejor cual es su opinion??? o Alguna convinacion?

[HackmanC]

Hola,

Una opinión adicional ... la validación de información debe ser reforzada en la capa de lógica de negocios.

Ya existen muchos patrones de diseño que se encargan de este problema y que han funcionado durante mucho tiempo de forma muy eficiente, y aún las empresas mas grandes en producción de software para desarrollar aplicaciones las siguen implementando.

El patrón que ha mi me ha sido de utilidad durante mucho tiempo en todos los lenguajes de programación que he usado, es crear aplicaciones de varias capas n-Tier applications, no confundir con el patrón MVC.

El paradigma es simple, la capa de lógica de negocios se encarga de realizar todas las validaciones y acciones que representen reforzar los estándares de una compañía. Y esta debe estar completamente separada de la base de datos y de la vista, por el hecho que puede correr en un servidor o cluster completamente diferente (RPC), esto da escalabilidad y estabilidad a un proyecto. La misma lógica se puede reutilizar en aplicaciones de escritorio, web y webservices al mismo tiempo sin duplicar la lógica en cada aplicación.

La capa de lógica de negocios se encarga de validar que los datos estén correctamente ingresados y que cumplan ciertos requisitos que en algunos casos ni la base de datos tiene la capacidad de reproducir, como el caso de manejar información externa. Los datos no solo están almacenados en bases de datos, también pueden provenir de otro tipo de fuentes de información.

El hecho que Oracle permita procedimientos almacenados en Java en la base de datos u Microsoft SQL Server permita también código CLR dentro de la base de datos simplemente es para facilitar algunos procedimientos puramente de la base de datos, no para reforzar ningún tipo de lógica de negocios.

Se puede utilizar Javascript para validar información en la Vista solamente como un valor agregado, una comodidad extra para el usuario. Y reforzar la lógica de negocios en la base de datos porque algún día vas a querer cambiar el lenguaje de programación es absurdo ... ¿que pasa si quieres cambiar la base de datos? sucede exactamente el mismo problema.

Pero esta es solamente mi opinión al respecto,
Saludos,

[AlvaroG]

Ya puestos, ¿validar qué?
¿seguridad de los datos? obviamente mientras menos capas pasen mejor. Los datos que se sospeche sean producto de XSS o intento de inyección SQL no deben pasar más que el servidor.
¿validez en el sistema (que cumplan las "reglas de negocio")? eso creo que puede hacerse tanto en el servidor de aplicaciones como en el de base de datos, dependiendo de las características específica del sistema.

No es lo mismo validar que mi formulario de comentarios no esté siendo abusado para meter cosas en la BBDD, que validar que el usuario que lo envía haya ingresado todos los campos, o que los haya ingresado de forma correcta ("el nombre de usuario debe ser menor que x caracteres"). En el primer caso por supuesto los datos no deben llegar a la BBDD, en el segundo y tercero mejor detectarlo lo antes posible para no causar tráfico inútil, pero la validación se puede hacer de igual forma en cualquier capa de la aplicación (al menos mientras hablamos de web)

Creo humildemente que la separación en capas no necesariamente debe ser "html - php - sql", y que la BBDD sí puede ser parte de la capa de negocio, ya que dependiendo de la aplicación esto puede tener alguna ventaja. Después de todo, los datos están en la base, y si siempre se requerirá que se entreguen de cierta forma, ¿no se puede simplemente acceder a través de procedimientos y obtener los datos tal cual se los necesita?


Saludos.

[HackmanC]

Hola,

Iniciado por AlvaroG

... dependiendo de las características específica del sistema. ...

Bueno, creo que allí lo resumiste bastante bien.


Por aparte, solo voy a agregar un ejemplo, hay un sistema corporativo que tiene 3 aplicaciones diferentes, una aplicación de escritorio hecha en VB6 para cargar información y consultar por teléfono con operadora, una aplicación web echa en PHP para modificar y consultar por web y un webservice en .NET para intercomunicación con otras empresas, además de algunos otros componentes de intercomunicación con otras aplicaciones en Java y ASP. El sistema cuenta con 600 tablas principales en 2 bases de datos diferentes PostgreSQL y Oracle (la mitad en cada una).

Hay una regla de negocios que dice: cada consulta a cualquier tabla se cobra, si la consulta tiene mas de 30 datos, lleva 'urgente' en algún campo, consulta mas de 8 tipos de información, o si la consulta se hace fuera de horas hábiles el precio es el doble.

Ahora vamos a hacer la validación en Javascript, o en la BD. Y verifiquemos si es numérico el campo ID y revisemos inyección de SQL en cada aplicación. Y hagámolo transaccional, no consulta no cobro.

Si no tienes tu BusinessRules centralizado en WebServices ... buena suerte !

Evidentemente yo no hablo de un blog con 12 tablas, a menos que no tengas pensado crecer nunca (que es completamente válido) no necesitas pensar en nTier ni MVC, unos cuantos archivos en PHP's sin POO te quedan bien y así no usas ni siquiera dos capas.

Saludos,

ps:
Ese sistema no es hipotético.

[emprear]

Iniciado por Ojete

Gracias a todos por sus comentarios creo que me a quedado un poco mas claro mas o menos....

Ojete, no te asustes, por este foro las cosas son asi, lo que habla de su nivel. Y tu "más o menos", me arrancó una sonrisa

saludos

[maycolalvarez]

en términos y estándares de seguridad web, es indiscutible la validación por el servidor, aunque esto implique sacrificar el rendimiento, la idea de un servidor es centralizar lo procesos para otorgar un servicio seguro, trasparente y confiable al cliente.

si bien es cierto que puedes realizar ciertas validaciones en la base de datos, ¿la misma no corre en un servidor?, caemos en el mismo principio: validaciones en el servidor, muchos sistemas echos en php, asp u algún otro script del lado del servidor realizan sus validaciones para ser lo más independientes de la base de datos (model MVC) y con ello poder elegir a voluntad el SDBMS que satisfaga sus necesidades, el objetivo de los PL es abstraer lógica de negocio, pero no es la única vía.

javascript fue desarrollado para alimentar la interfaz del usuario, obviamente validar desde él garantiza al servidor ahorrarse la tarea de validar, pero siempre queda el problema de seguridad en el cual el servidor no puede confiar a ciegas del cliente, porque es muy simple desactivar js y enviar los datos sin validar, o en casos de que el usuario sea víctima de Phishing, ¿si en mi servidor no valido CSRF ni filtro XSS, como hago?: javascript no puede ayudarme aquí, ni menos la DB, quedando php.

@Ojete: yo siempre soy participe de que uno debe crearse su propio criterio, corregirse es de sabios, así como también seguir la corriente, en mi experiencia como programador he notado que siempre se debe validar en el servidor, y no soy el único que permanece en este barco

[naciostars]

AlvaroG...muy buen aporte XD

[naciostars]

Bueno, Ojete...la idea es que tengas en cuenta las experiencias de todos...para que no tengas que iniciar de 0 =)....exitos y gloria en tu recorrido por este interesante mundo =)

[Ojete]

Una ves mas "Gracias" a todos.

Y ya para resumir podrian aportar alguna conclucion en una breve frase? maxlength="30" tal ves se convierta en celebre...

[igualacero]

Hola buenas, cada uno de ellos tiene sus ventajas dependiendo de que parte de la web que se va a validar. Es lógico que las validaciones del lado del servidor sean más fuertes en cuanto a seguridad pero dependiendo de para que se puede usar javascript especialmente para la inserción de datos en formularios simples o de contacto.
Pero no se trata de cual es mejor sino de cual es mejor dependiendo de lo que vayas a realizar.

[cristian_db]

realizar validaciones del lado del cliente tiene sus ventajas
ya que el usuario, al ingresar un dato incorrecto, aparecería al instante, esto hace que todo sea más dinamico. En vez de enviar el formulario, que el servidor lo procese y esperar si esta todo bien...
pero a nivel seguridad, deja mucho que desear, por eso creo que lo mejor sería implementar las 2 validaciones....