Con la gente del grupo Web & Beer armamos un checklist de los puntos importantes con los que debería cumplir una web antes de salir a producción. Estos puntos que se van a mencionar son importante en cualquier desarrollo web, y contempla la mayoría de los problemas. Es importante que chequeen estos puntos en sus desarrollos actuales, y traten de evitar tener problemas con los nuevos sistemas que vendrán.

- Validar formularios y entrada de datos desde el lado del cliente y desde el lado del servidor.
Este punto es uno de los mas importantes, muchos programadores validan los datos desde uno de los dos lados, o del cliente o del servidor. La idea es que siempre se validen los dos. Se podría obviar la validación del lado del cliente, pero nunca del lado del servidor, nosotros tenemos que saber que datos y de que tipo son los que entran en nuestro sistema. Para eso tenemos que comprobar si es alfanumérico, si es numérico, si es un mail, etc. No hay conformarse solo con validar los datos desde javascripts, ya que esto puede ser filtrado. La validacion del lado del cliente sirve para que no hagamos esperar al usuario mientras se procesan los datos en el servidor, sino escribió un dato en un campo obligatorio no lo dejamos enviar el formulario. Con un simple plugin de firefox puedo cambiar los datos que se envían por post agregando lo necesario para hacer un sql injection. Hay que chquear que la cantidad de caracteres que pueda ingresar sea igual o menor que la capacidad del campo que va a guardar este dato en la base de datos.

- Validar Claves y nombre de usuarios de los usuarios del sistema.
Los usuarios no pueden tener claves de 2 o 3 letras, tienen que tener claves seguras o por lo menos lo mayor posible, deberíamos asegurarnos que una clave sea de por lo menos 5 caracteres y no sea igual que el usuario, o no permitir secuencias de números o 5 datos repetidos como 55555, no estaría mal validar que los usuarios no ingresen claves que esten dentro de las claves mas comunes, como qwerty, 123456, dios!, miclave, password, etc. Esto es para darle cierta seguridad a nuestro sistemas y evitar casos de phishing. Otra cosa que veo muy seguido es que muchos validan que la clave sea alfanumérica, pero si quiero poner una clave del estilo ph1s#u!r no podría. Se debería permitir este tipo de claves ya que es mucho mas segura que una alfanumérica. Lo mismo con los usuarios, minimamente tienen que tener 5 caracteres y en lo posible alfanuméricos. Estoy viendo cada vez mas seguido web que usan los mails como nombre de usuario.

- Encoding.
Este tema es muy problematico, quien no ha tenido problemas con este punto?. Tenemos que ser homogeneos y elegir siempre el mismo encodign, el ideal es utf-8 ya que es con el que trabajan los servidores unix donde estarán alojados la mayoría de los sistemas web. Hay que revisar que los archivos que usemos, y las cabeceras de los xhtml que estén en utf-8, también tenemos que asegurarnos que nuestra base de datos este guardando los datos en utf-8.

- Paginas de errores.
Cuando alguien intenta acceder a una url de nuestro dominio que no corresponde a ninguna pagina activa, deberíamos mostrar un error personalizado de 404 y agregar links que lo dirijan a la home de nuestra web o a un buscador de contenidos.

- Cross Browser.
El gran dolor de cabeza de cualquier desarrollador. Esto es algo muy difícil de lograr ya que muchos navegadores implementan su propio estándar y no siguen el de la w3c, digase ie6, ie7, ie8. Pero también hay que saber que los navegadores interpretan algunas cosas de forma diferente por eso es ideal probarlo en distintos browsers para que no se rompa el diseño.

Es probable que tengas que usar Css Hack para que tu sitio sea cross browser

Puedes usar Browsershots para ver una screenshot de tu web en diferentes navegadores

- Evitar archivos de configuracion dentro del webroot.

Este es otro de los puntos de seguridad grave que podemos llegar a tener.  Los archivos de configuracion que tiene los datos de acceso a la base de datos o accesos a web services tienen que estar fuera del webroot de nuestro sitio.

Estos son aspectos generales, pero ahora vamos a hablar de algunos puntos en cuanto a la accesibilidad y el SEO.

- Sitemap.
Es importante que si quieren que su sitio sea indexado por los buscadores tengas un sitemap, y den de alta el mismo en estos buscadores. Dice la leyenda que si tu sitemap tiene el nombre sitemap.xml, google lo indexa mejor que si fuese sitemap.php o cualquier otro nombre.

Wikipedia

- Imagenes.
Las imagenes son un ingreso de visitas importantes si se usan adecuadamentes. Hay dos puntos necesario para manejar las imagenes y conseguir visitas con ellas, tener un alt con la descripción de la imagen, y que el nombre del archivo haga una descripción del mismo, por ejemplo cristina_kirchner_en_la_rosada.jpg, si se fijan cuando ustedes buscan una imagen en Google Images se van a dar cuenta que usan estos dos criterios para la búsqueda.

- Paginas internas

Cada pagina que tenga nuestro sistema debería tener la descripción de esta en la url. Esto se llama clean urls, y se ve mucho en los cms, que nos permiten que el acceso a una pagina en vez de ser http://dominio.com/noticia/index.php?newsId=342 se convierta en http://dominio.com/noticia/newsId/342/ esto es mas claro que lo que vimos en el ejemplo anterior, perotambién podríamos mejorarlo mucho mas si nuestra url luciera así http://dominio.com/news/342_cristina_aumenta_sueldo_a_los_jubilados.html. Google indexa mejor los contenidos donde su url describe el contenido que va a mostrar. Esto es facil de solucionar agregando alias a nuestras paginas, o creando alguna regla de rewrite que maneje este problema, los que usen ZF pueden usar Zend_Route , pero siempre seria mas optimo que lo hagan desde .htaccess.

Si tu sitio tiene bajo control estos puntos te invito que revises los otros puntos creados por la gente de Web & Beer.

Actualmente una empresa no solo tiene una web institucional, sino que muchas veces ofrecen servicios a través de esta y/o manejan una intranet/extranet y esto genera que tenga muchas aplicaciones con diferentes sistemas de usuarios, e información duplicada.

Pero como estructurar una aplicacion donde van a convivir varios tipos de usuarios en una misma estructura sin generar conflic

tos ?.

Lo que voy a plantear en este articulo es una estructura genérica para un problema especifico.

El problema es la unión de todas o casi todas las aplicaciones de una empresa que presta servicios online donde se unifique el flujo de la información.

Una empresa que tienen 5 aplicaciones no necesariamente tiene que tener toda su información repartida en 5 base de datos diferenntes Pueden llegar a compartir la misma base, o tener una base donde se unifica cierta información compartida. O si,  tener diferentes bases para cada subsistema, pero compartir la información común a través de los mismos sistemas sin la necesidad de duplicar una interfaz para administrar esa informacion o peor aun duplicar información corriendo el riesgo de generar una inconsistencia de datos.

Recuerdo mis tiempos en la UCA donde cada departamento tenia aplicaciones diferentes, desarrolladas independientemente por diferentes personas o grupos, sin una integracion clara entre ellas. Estoy seguro que hasta el día de hoy los alumnos se deben quejar porque tienen que loguearse con diferentes usuarios y claves, para distintos servicios que supuestamente están alojados en el mismo lugar.

Pero este no es solo el problema de una institucion con la embergadura de una empresa con mas de 10000 empleados. Este problema puede ocurrir en cualquier ámbito, hasta en una pymes, donde cuenta con dos o tres sistemas que son independientes entre si.

Los sistemas o subsistemas pueden relacionarse de manera muy fácil, y esto generalmente va a requerir menos horas de desarrollo que aplicaciones totalmente independientes, teniendo en cuenta que siempre habrá que administrar módulos de forma independientes.

Tengo que volver a mencionar la posibilidad de un servidor de usuarios, pero no crean que por referirme a algo como un servidor, implique costo de hardware y mantenimiento, esto puede estar alojado en una pc cualquiera compartiendo espacio con el resto de los sistemas. Un servidor de usuarios me parece la implementación perfecta, porque cada sistema siempre va a tener independencia a través de su dominio, pero va a evitar el re ingreso de creación de usuarios, permisos, y logueos, para un usuario con acceso a varios de los subsistemas.

Voy a dar un ejemplo simple, un programador de la empresa Zeta, cuando ingresa a trabajar se loguea en el sistema de ticket de su empresa para ver que cosas están pendientes. Luego de terminadas, se loguea en el sistema de horas, para cargar las horas trabajadas durante el día, al final del día decide agregar una entrada al blog de la empresa explicando uno de los descubrimientos que hizo.

Esto genero que el usuario tenga que tener cuenta en los 3 sistemas con los que trabajo, y no solo tener una cuenta sino que además se tiene que loguear en las tres.

Esto por ahi si hablamos de un programador no es problema porque esta acostumbrado. Pero supongamos que es un cliente que tiene su sitio web de ventas de remeras, y necesita revisar en el panel de administración si están al día las ultimas promociones que publicito,  revisar el trafico de visitas o de ventas del mes en el sistema de estadísticas del sitio, después revisar si entraron nuevos productos al tracker para poder procesarlos y despacharlos. No solo eso después va a querer agregar un ticket al sistema de ticket de la empresa Zeta porque uno de los módulos necesita una funcionalidad nueva. Y otro vez se va a loguear en el sistema de horas, para saber si todavia cuenta con horas disponibles dentro de su paquete mensual o necesita comprar mas.

Ahora el tema es mas complicado porque el tedioso trabajo de loguearse en cada aplicacion no lo hace el empleado que no le llega a molestar, sino lo hace un ejecutivo o un comerciante que no necesariamente se tiene que acordar de sus 20 claves, para los diferentes sitios. O peor aun tiene que usar claves muy simples para no olvidárselas o una única clave repetida.

Y esto es lo que se ve de afuera, porque por dentro seguramente tengamos un sitio web desarrollado con drupal con su base de datos MySql, un sistema de estadísticas hecho con alguna herramienta de reportes, un sistema de tracking desarrollado por nosotros al igual que el sistema de horas, y  el Trac o Mantis para administrar ticket.

Todos estos sistemas con Base de datos diferentes y datos duplicados, cada uno con su sistema de administración, donde damos de alta a los usuarios y sus permisos.

Todo esto se puede simplicar de sobre manera con un sistema de usuarios integrados. En otro articulo ya mencionamos teóricamente como crear esto, quizás me inspire y suba algún código que haga esto para evitar que pierdan tiempo pensando como hacerlo.

Le doy una extremada importancia al tema usuarios porque lo veo con Clientes que se quejan de esa falta de integracion y se que es molesto para ellos y se podría solucionar de forma muy fácil. Pero también podemos ver el tema de reportes.

No necesariamente para generar reportes hay que duplicar los datos de otras bases, de hecho este ejercicio a veces consumo muchos recursos que no queremos desaprovechar. Podemos reutilizar la base en el mejor de los casos o buscar otras medidas.

Un punto interesante es  que nosotros podemos usar aplicaciones pre-armadas como Drupal, trac, PHP Report, etc  y con algunos ajustes adaptarlas a nuestro sistema de integracion de usuarios. Cada sistema implementa su propia forma de autenticación pero nosotros podemos tomarnos el trabajo de mirar 15 minutos para ver como funciona su sistema de loguin e integrarlo en nuestro servidor de usuarios. El caso de Drupal es mucho mas simple ya que cuenta con un webservice para administracion de usuarios entre ellos el login y logout.

Escribir esto medio ganas de armar el sistema de usuarios y compartirlo para que vean lo fácil que se puede integrar.

Otro punto a destacar es que podemos interconectar nuestros sistemas a través de webservices sin la necesidad de que compartan la misma conexion de base de datos. O el mismo servidor.

Espero ver mas sistemas integrados después de esto. Quizás algun dia, pueda entrar a mi pc, abrir el navegador loguearme en una pagina X y acceder a todas mis web autenticandome unicamente en la pagina X, quizas el openId logre esto. Veremos, mientras tanto voy a seguir usando el administrador de cuentas de firefox (cuidado que este guarda la clave de forma plain en el filesystem ).

PHP Report Maker ( http://www.hkvstore.com/phpreportmaker/ )
Drupal (http://drupal.org)
Mantis ( http://www.mantisbt.org/ )
Trac ( http://trac.edgewall.org/ )