[LUG.ro] Re: [LUG.ro] Proyecto suscripción a jornadas

[Andrés D'Elia]

Omar,

No se si esto me habilita como colaborador, pero les hago un comentario para ver si es
parte del proyecto inicial.

Dado que va a ser una aplicación que va a manejar datos de personas, potencialmente
sensibles, creo que se debería diseñar pensando en implementar protección de esa
información. Las variantes pueden ir desde un esquema de seguridad de usuarios con
distintos perfiles con control de acceso (desde la aplicación o de la base de datos si es
el soporte elegido), encriptación en el soporte de datos e incluso si esta posibilidad va
a ser mandatoria o si se puede elegir al instalar el tipo de protección a usar. Esto va
más allá de validar entradas o evitar un ataque por inyección SQL, buffer overflow y/o/u
otras yerbas.

No tengo mucha experiencia en el desarrollo de este tipo de aplicaciones pero creo que
vale la pena decidir de arranque si este aspecto se va a contemplar en el diseño inicial
o bien será un To-do para otra etapa.

Saludos,

Andrés


 --- Arino Omar <ArinoO@bancobsf.com.ar> escribió:

> Acá envío un bosquejo del paper del proyecto, a fin de que los colaboradores los vean y
> envíen sus sugerencias y correcciones.
> 
> Proyecto: ADMINISTRACIÓN DE SUSCRIPCIONES.
> 
> Nombre tentativo: JORNADAS LIBRES.
> 
> Plataforma de desarrollo: PHP 4 
> 
> Herramientas auxiliares: 
> Base de datos: MySQL o Postgress. (Ver objetivos)
> Servidor Web: Apache, evaluar compatibilidad con otros posibles servidores.
> Librería de desarrollo: NY
> 
> Objetivo:
> 
> El objetivo del proyecto es poder contar con un sistema flexible de administración de
> datos, para gestionar suscripciones a eventos varios (jornadas, congresos, etc.), que
> permita obtener datos vía web, y manipular la información obtenida para, registrar la
> asistencia, emitir comprobantes, etc.
> La información obtenida vía web debe ser almacenada de varias formas, ya sea en una
> base de datos SQL, en un archivo de texto plano o enviada por correo. Dependiendo la
> forma en que se almacenó el sistema debe permitir de manera simple recuperar esa
> información para ser transportada a otro lugar, para su reprocesamiento.
> El sistema debe contar con una interfase clara para poder ser expandido de acuerdo a
> las necesidades propias del usuario. De ser posible se debe contar con un modulo de
> configuración que simplifique la configuración del sistema.
> El sistema debe contar con un instalador y estar perfectamente documentado.
> Todo el código fuente debe estar comentado para una correcta compresión de su
> funcionamiento, ante la falta de comentario en las modificaciones aportadas estas serán
> rechazadas.
>  
> Definición de módulos:
> 
> a)	Obtención de datos
> 	Este modulo debe proveer un formulario web que permita al interesado ingresar todos
> los datos definidos por el usuario. En una primera instancia los campos ingresados
> serán estáticos, hasta tanto se defina un método simple para configurar los datos
> obtenidos y su futuro reprocesamiento.
> 
> 	Verificación de la integridad de la información.
> 	Cuando los datos son ingresados en el formulario web estos datos deben validados
> siguiendo determinados parámetros, como ser en datos filia torios que se ingrese texto,
> en campos numéricos que solo tomen números, en direcciones de correo que se ingresé una
> dirección válida. Para lograr esto y previendo que la información ingresada en el
> formulario puede variar a pedido del usuario se deben definir tipos estándar de datos
> para poder realizar la validación que para lograr mayor eficiencia se realizará
> utilizando expresiones regulares, y no por medio de java scripts a fin de lograr mayor
> compatibilidad con los distintos navegadores. 
> 
> 	Almacenamiento de la información
> 	A fin de flexibilizar la aplicación, la información obtenida debe poder soportar
> varios modos de almacenamiento, de acuerdo a las necesidades y posibilidades del
> cliente. Esto medios son en un servidor SQL, en uno o varios archivos de texto plano o
> enviados por correo electrónico.
> 
> 	Comprobante de registración
> 	El sistema emitirá un comprobante de registración para que el interesado cuenta con un
> pre-comprobante que agilice la comprobación de datos cuando se presente en el evento.
> (Este elemento puede ser utilizado de al manera que más crea conveniente el cliente).
> 
> b)	Recuperación de datos
> 	Los datos ingresados desde la web deben poder ser recuperados por el cliente de manera
> remota. Para lograr este objetivo se debe proveer de una interfase para la captura
> remota de los datos, ya sean estos almacenados en los tipos anteriormente detallados.
> 
> c)	Procesamiento de datos
> 	Una vez recuperada la información debe estar disponible para su utilización.
> 	El sistema local de procesamiento contará con los siguientes módulos:
> 1)	Alta. (para ingresar información de personas no registradas vía web) Esta
> información validará contra los datos obtenidos de la web a fin de evitar
> duplicaciones. Se puede verificar contra el comprobante de registración web. Este puede
> ser una clave generada con la hash MD5 correspondiente a la unión de los campos
> Apellido, Nombre y Email.
> 2)	Modificación. Permite corregir los datos ingresados en la web.
> 3)	Baja. La baja debe ser solo una marca correspondiente a un posible error. El
> registro original nunca debe ser eliminado fisicamente.
> 4)	Acreditación. Este modulo servirá para acreditar a los asistentes. Debe permitir
> buscar por cualquiera de los campos de la registración y por el comprobante de
> registración. Además debe permitir modificar los datos o ingresar datos nuevos
> (relación con los puntos 1 / 2 / 3). Debe emitir un comprobante de acreditación el cual
> debe imprimir los datos definidos por el cliente.
> 5)	Listados e impresiones.
> 		Este modulo debe permitir la emisión de listados, certificados definidos por el
> cliente o reimprimir cualquier comprobante emitido. A fin de poder llevar un control
> estricto de estos debe llevar un contador de la cantidad de veces que se emitió. 
> d)	Modulo de administración
> 	Este modulo debe permitir al usuario la configuración y adecuación a sus
> especificaciones.
> 
> Reglas y normas comunes de desarrollo:
> 1)	Nombre de variables : se utilizará el método camello para los nombre. En el caso de
> variables todas empezarán en minúsculas, en el caso que se utilicen mas de una palabra
> para formar su nombre, no contendrán espacios, no estarán separadas por guiones y deben
> ser representativo de lo que almacena,  la primer palabra se pone en minúscula y la
> siguiente deben empezar en mayúscula, por ej.: apellidoNombre
> 2)	Funciones: se utilizará el sistema doble camello. El nombre no contendrán espacios
> y/o guiones empezarán con la primer letra en mayúscula y las restantes en minúsculas y
> en el caso de estar formadas con más de una palabra, cada una de ellas empezarán en
> mayúsculas, ej.: ApellidoNombre.
> 3)	 Todas las variables serán tratadas como inseguras. Para esto se debe deshabilitar
> la opción GLOBAL_REGISTER asignándole el valor OFF. Además se deberá filtrar toda las
> variables recibidas para evitar posibles ataques, limpiándolas de códigos HTML, etc.
> 4)	Todos los formularios enviarán sus datos por el método POST.
> 5)	Todos los parámetros se enviaran por el método GET (a través de la url).
> 6)	Todos los campos de los formularios se trabajarán como ARRAY, para facilitar la
> limpieza del contenido.
> 
> Integrantes del proyecto TODO NOSOTROS!!!!!
> 
> 
> 
> Omar Arino
> 



	


	
		
___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar