ALUMNO:

GUILLERMO VAZQUEZ GONZALES

TRABAJO:
ACTIVIDAD FINAL DEL CURSO

Asignacin a cargo del Facilitador

Problemas tpicos de la programacin Web

Formularios y CGI
HTTP, se caracteriza por ser un protocolo stateless, es decir, en el cual no se
mantiene informacin de estado. Las transacciones se ejecutan con un
requerimiento de un lado y una respuesta del otro. Esta aproximacin puede parecer
bastante simplista en el terreno de las aplicaciones cliente-servidor. Ninguna de las
aplicaciones anteriores (FTP, Telnet) es stateless, con la posible excepcin de NFS.
De hecho, NFS se implementa sobre el protocolo UDP, ni siquiera TCP. Esto porque
est en mente principalmente el objetivo de conseguir buenos tiempos de respuesta,
a costo de todo lo dems. Por otra parte, por la implementacin en mltiples
procesos de la mayora de los servidores, es raro que dos requests consecutivos
del mismo cliente sean atendidos por el mismo proceso.
En el caso de HTTP, esto puede llegar a ser un problema mayor. La forma en que
CGI+HTML resuelven el tema de las aplicaciones Web es realmente muy limitada:

El usuario llena un formulario HTML y presiona "submit"

El servidor recibe el formulario HTML, lee las variables que hay en l, ejecuta
algn efecto colateral y despliega otra pgina (posiblemente con un
formulario tambin).

Formularios
Un formulario es un dilogo que forma parte de una pgina Web. Este dilogo est
construdo con un conjunto de elementos como:

Campos de texto de una o varias lneas

Checkboxes (opciones no excluyentes)
Radio buttons (opciones mltiples excluyentes)
Pull-down menus
Botones

Algunos de estos elementos tienen un nombre. Este nombre indica que el valor
actual del elemento debe ser codificado y enviado al servidor en el momento del
envo del formulario. Ms informacin en WDVL - Forms.

Preclculos y Validacin en el lado del cliente

Es algo estndar actualmente que antes de enviar el formulario, un programa
corriendo en un lenguaje embebido en el browser del cliente (tpicamente
Javascript) realice algunos clculos. En la prctica esos clculos significan detener
el proceso de envo al servidor, bajo ciertas condiciones, generando una alerta al
usuario. En otras ocasiones significan que algunos elementos del formulario
adquieren nuevos valores que son calculados automticamente en base a otros.
El ejemplo ms tpico de preclculo son los formularios que validan dgitos
verificadores antes de que el usuario enve la pgina.
El proceso de prevalidacin tiene las siguientes ventajas:

Ms rpido detectar errores

Menos carga del servidor

Notar que la prevalidacin puede simplificar la programacin de los scripts en el lado

del servidor, pero eso no implica dejar de hacer ciertas aserciones para evitar uso
malicioso (ej.: ingreso de una URL con variables directamente).
Proceso del formulario en el lado del servidor
El servidor recibe slo pares del tipo nombre=valor. Normalmente el sofware en el
lado del servidor tiene acceso a todos los recursos de esa mquina y por lo tanto
puede ejecutar cualquier programa, conectarse a otros servidores, y producir
cualquier tipo de efecto colateral que desee.
Desde el punto de vista funcional, este programa recibe entradas y genera una
salida. Esta salida puede ser de cualquier tipo MIME aceptado por el browser que
envi el formulario. Lo ms tpico es HTML pero no es raro ver imgenes generadas
tambin (esto se usa en los ad-servers y todas las herramientas de user-tracking
para estudiar patrones de navegacin).
Hay varios problemas aqu:

Qu pasa cuando no necesito desarrollar algo ms complejo?

Qu pasa si necesito varios pasos?
En particular, qu pasa si hay un paso previo de autentificacin?

Estas preguntas tienen toda una respuesta afirmativa, es decir, siempre hay
solucin. Pero contestar eso es lo mismo que decirle a alguien que es perfectamente
posible hacer un programa que simplifique expresiones de algebra simblica
usando mquinas de Turing: se necesita en la prctica una forma de ms alto nivel
de describir el problema.

Lo extrao de todo esto es que normalmente no se busca tal forma, sino que
simplemente se intenta parchar con las herramientas disponibles. Veremos una
situacin intermedia en que la aplicacin es complementada por ciertos mdulos de
nivel medio.

Sesiones
El problema de la persistencia es central al comenzar a pensar en este problema en
un nivel un poco ms alto. Por persistente significa que la aplicacin requiere del
envo y respuesta de mltiples formularios, y que esta secuencia de envos y
recepciones requiere cierta coherencia.
Esta coherencia se logra permitiendo que en algn nivel los programas trabajen con
los datos como si el proceso de enviar y recibir datos fuera algo continuo. Por lo
mismo, en algn nivel inferior la aplicacin debe transformar los envos de datos de
formulario entre browser y servidor en alguna estructura ms coherente. Estos
envos de datos constituirn una sesin.
La solucin consiste en mantener en el lado del servidor un conjunto de datos
correspondientes al cliente. Estos datos van ms all de su identificador como
usuario, sino que pueden involucrar tambin sus respuestas en formularios
anteriores, patrones navigacionales, etc. Estos datos son almacenados
normalmente en una base de datos relacional o en un rea de datos compartida
entre los procesos de atencin del servidor web.
Para conectar estos datos con el usuario, se utiliza por lo general una cookie. Esta
cookie incluye un identificador de sesin (session-id) generado aleatoriamente y que
por motivos de seguridad puede codificar entre otras cosas la IP del browser, fecha
hora actual, etc.
Las sesiones se pueden implementar tanto a nivel del servidor como de la
aplicacin, con o sin bases de datos y con o sin cookies (a veces se emplean URLs
codificadas y mtodos de reinterpretacin de URLs en el lado del servidor).

Persistencia de datos
Prcticamente todos los sistemas transaccionales en Internet tienen alguna forma
de guardar lo realizado durante la sesin, esto es, de hacer los cambios
permanentes. Lo tpico es utilizar algn SABD y comunicarse con l en SQL.
Secundariamente se realizan modificaciones a archivos en el filesystem o
conecciones a otros servidores.
Una buena idea es utilizar algn tipo de puente objeto-relacional en este caso. Esto
es, la aplicacin se construye en algn lenguaje con soporte para objetos
persistentes.
virtual class Persistent_Object { public result_code store(); public static
Persistent_Object Retrieve(query); // puede ser SQL, QBE, by_oid, etc. }
La implementacin de la clase base Persistent_Object excede el mbito de este
documento, pero pueden consultar ms informacin en ODMG - Object Data
Managment Group.
Seguridad
Confidencialidad
Las caractersticas de Internet que le son ms propias son las mismas que generan
una serie de problemas al momento de crear una aplicacin en el Web. Un paquete
de informacin puede pasar por varias manos antes de llegar a destino por lo que
no es fcil asegurar que no sea examinado o modificado.
Para conseguirlo normalmente se utilizan sistemas de llaves asimtricas, siendo lo
ms comn HTTPS que es HTTP sobre SSL.
SSL (secure socket layer) es un estndar desarrollado por Netscape que permite
una transmisin segura de datos.
Como en todo sistema de llaves pblicas, es deseable que existan entidades
certificadoras que permiten crear un web of trust apropiado.
Autentificacin
La autentificacin puede llevarse a cabo con o sin SSL. Sin SSL es imposible
asegurar demasiada seguridad, siempre alguien podr suplantar a menos que se
use un esquema de tipo challenge en que el servidor genera un token que debe ser
transformado por el cliente antes de responder.
Sin embargo a la larga esto ya es suficientemente complicado como para que sea
preferible usar SSL, que adems de autentificacin provee de confidencialidad.

Organizacin del cdigo

El problema de organizar el cdigo no es menor; debido a las circunstancias/estilo
deprogramacin hay varias decisiones que tomar:

Todo en un archivo
Varios archivos, uno por cada accin (tpico)
Varios archivos, uno por cada clase
Archivos de interfaz y bibliotecas por cada grupo de acciones

Una organizacin de cdigo inteligente tiene que ver con conocer:

Cules son las facilidades que da el servidor para precompilar cdigo?

Cmo convierto strings en llamadas a funciones?

Respecto a lo primero, es importante saber y determinar cules son las partes ms

variables del cdigo, para ponerlas directamente en los CGI, e ir estabilizando
bibliotecas ms permanentes que son precompiladas.
Respecto a la segundo, la mejor solucin es crear tablas de hashing que permiten
convertir en forma ms segura la peticin del usuario en una llamada a funcin.