\documentclass[a4paper]{article}
\usepackage{linuxdoc-sgml}
\usepackage{qwertz}
\usepackage{url}
\usepackage[latin1]{inputenc}
\usepackage{t1enc}
\usepackage[english]{babel}
\usepackage{epsfig}
\usepackage{null}
\def\addbibtoc{
\addcontentsline{toc}{section}{\numberline{\mbox{}}\relax\bibname}
}%end-preamble
\title{Artículo para la revista Linux Actual número 15:}
\author{Javier Fernández-Sanguino Peña {\em }
{\tt <jfs@computer.org>}}
\date{24 julio 2000}
\abstract{ En ésta entrega del desarrollo de bases de datos en Internet con GNU/Linux se van a ver los aspectos específicos del desarrollo de la
aplicación que ya se describió en los anteriores.}


\begin{document}
\maketitle

\section{Introducción}

Como ya se introdujo en el número anterior, la aplicación concreta
que se va a abordar es la creación de una Asociación de Antiguos
Alumnos en Internet, para que sea posible, a dichas personas, acceder
a través de un cliente universal (un navegador de WWW) a una base de
datos con la información relativa a los demás antiguos alumnos.

De esta forma esta base de datos puede servir para que los distintos
exalumnos puedan comunicarse entre sí, saber dónde se encuentra
trabajando cada uno y así estrechar los lazos que ya en su día se
generaron en el Instituto, Escuela o Universidad donde se conocieron.

La aplicación en concreto se dividirá en:

\begin{itemize}
\item una parte de introducción de información que sirva como alta de
los nuevos usuarios.
\item una sección de autenticación que permita acceder a los usuarios
reconocidos al área privada del servidor.
\item una sección de consultas, sólo accesible por los usuarios
reconocidos, que permitirá obtener información de la base de datos
\end{itemize}


En este artículo se van a ver todos estos aspectos de la aplicación,
acompañándolos del listado de código necesario para llevarlos a
cabo. Como ya se introdujo en los anteriores artículos, para implementar
esta aplicación se va a utilizar WWW-SQL (en su versión para
PostgreSQL). 



******************** FIGURA 1 *************************






\section{WWW-SQL}

Ya se vio en el artículo anterior una breve introducción al
lenguaje de programación de scripts WWW-SQL en comparación con otras
técnicas para programar el acceso a servidores de web desde páginas
HTML. Aquí se hará más hincapié en la estructura del lenguaje y en sus
posibilidades.

WWW-SQL es un programa CGI diseñado para crear páginas de web desde
bases de datos PostgreSQL o MySQL, implementado por James
Henstridge. El programa viene acompañado de un completo manual con
algunos ejemplos, pero aquí se resumen algunas de sus capacidades.



La función de WWW-SQL es procesar una página HTML e
interpretar determinadas órdenes contenidas en ésta, calcular los
resultados de ejecución de estas órdenes y devolver la página
modificada. Como el lector puede adivinar, las órdenes que va a
ofrecer el lenguaje van a estar, fundamentalmente, relacionadas con el
acceso a bases de datos.

La sintaxis de las marcas reconocidas por WWW-SQL es la siguiente:

{\ttfamily {$<$}! SQL orden argumento1 argumento2 ... {$>$} }

La {\ttfamily orden} es cualesquiera de los comandos reconocidos por
el lenguaje, mientras que {\ttfamily argumento1} y {\ttfamily argumento2}
(aunque puede haber más argumentos) son los datos que se le dan a
dicho comando para variar su comportamiento.

Algunas de los comandos más importantes en WWW-SQL  son:
\begin{itemize}
\item {\bfseries connect}: permite conectarse a un servidor de
base de datos indicando el nombre del servidor y el del usuario (y
contraseña) utilizados para acceder a ésta. Si no se da nombre de
usuario se utilizará uno por defecto.
\item {\bfseries database}: indica la base de datos del sistema
de base de datos a utilizar, y es absolutamente necesario para llegar
a conectar a una base de datos.
\item {\bfseries close}: cierra la conexión a la base de datos,
debe ser el último comando a ejecutar.
\item {\bfseries query}: permite hacer una consulta SQL
cualquiera a la base de datos y devolver los resultados a través de un
elemento que podrá utilizarse para extraerlos.
\item {\bfseries set},{\bfseries setdefault} y
{\bfseries setexpr}: permite trabajar con variables dentro de
WWW-SQL, asignándolas valores. Se pueden modificar las variables y
comparar a través de un conjunto de operandos que incluyen, incluso,
expresiones regulares.
\item {\bfseries free},{\bfseries fetch} y
{\bfseries seek}: permite hacer operaciones sobre los elementos
devueltos del resultado de las consultas.
\end{itemize}


Además, el lenguaje tiene soporte para dos tipos de estructuras de control
({\ttfamily if.. then...elseif..endif}, y {\ttfamily while..done}),
posibilidad de gestionar las variables recibidas a través del CGI
script (rellenadas, por ejemplo, desde un formulario), capacidad de
gestionar Cookies y algunas estructuras ya implementadas para poder
gestionar fácilmente tablas y algunos elementos de formularios (como
listas desplegables).

La estructura normal de una página con SQL embebido con este lenguaje
tendrá, típicamente, esta estructura:
\begin{tscreen}
\begin{verbatim}
<!-- Cabeceras HTML -->
<!sql connect>
<!sql database dbname>
<!-- código HTML y órdenes www-sql -->
<!sql close>
<!-- Pie HTML -->
\end{verbatim}
\end{tscreen}




Un programador experimentado podrá echar en falta muchas capacidades
como: estructuras de control más potentes, la posibilidad de
modularizar el código a través de funciones, etc.. pero WWW-SQL es en
realidad la alternativa menos compleja para abordar el desarrollo de
los sistemas que aquí se están tratando. Si uno desea un lenguaje más
expresivo puede probar con PHP/FI o con PERL embebido. 

En cualquier caso, WWW-SQL es la alternativa más interesante cuando se
quiere hacer el desarrollo de un prototipo, lo que se llama comúnmente
"prueba de concepto".




\section{Desarrollo del servidor.}

El esquema general del servidor se muestra en la figura 2. Como se
puede ver en ésta el servidor se va a dividir, fundamentalmente en dos
partes, una parte de contenidos públicos, en los que no se va a
restringir el acceso al usuario y una parte de contenidos privados en
los que se va a solicitar una autenticación previa.

Por otro lado, es necesario tener alguna forma de que
los usuarios nuevos del servidor introduzcan sus datos para darse de
alta por primera vez.

***************** FIGURA 2 ***************************

Además, en este tipo de sistemas en los que se va a almacenar
información personal, será necesario cuidarse de que los usuarios que
se dan de alta son reales. Ésta sería la función de un "certificador"
(o notario), que diera fe de que los datos introducidos corresponden a
una persona real y que puede pertenecer por pleno derecho a la
asociación. Ésta figura y la forma de introducirla no se va a ver en
este artículo pues se sale del esquema propuesto de desarrollo. En
cualquier caso en esta serie se pretende hacer una exposición del
problema técnico existente no del problema también en sus aspectos
sociológicos (pero que en cualquier caso no se deben olvidar).

Evidentemente, para que el servidor tenga una cierta uniformidad en
cuanto a aspecto, las páginas tendrán que facilitar al desarrollador
que "obvie" los aspectos correspondientes a la parte estética y se
pueda centrar en el desarrollo de la aplicación. Esto puede hacerse
fácilmente haciendo uso de WML (Website Meta Language), este tema es
muy interesante pero se sale del ámbito de este artículo.

Como el lector puede suponer, la parte del desarrollo del servidor en
la que se va a hacer hincapié es la parte de la programación en el
interfaz del acceso a la base de datos, así como la parte de
autentificación. Se va a empezar con la entrada de nuevos usuarios, es
decir el alta de los mismos, y se podrán empezar a ver algunas de las
potencias (y debilidades) de WWW-SQL.




\subsection{Alta de usuarios.}

El alta de usuarios se hará, como es habitual a través de un
formulario de entrada HTML en el que el usuario rellenará los datos y
enviará éstos al servidor al pulsar el botón de "Envío".

La función del servidor una vez llevada a cabo esta tarea sería:
\begin{itemize}
\item comprobar que los datos tienen el formato adecuado.
\item introducir estos datos en la base de datos y detectar los
problemas que puedan surgir.
\item decidir si seguir adelante solicitando más datos y proceder
si es necesario.
\end{itemize}


El último paso es necesario para que se haga la entrada de los datos
en dos partes. Como ya se vio en el esquema entidad relación, en
principio todos los usuarios registrados tienen que tener un conjunto
de datos, pero hay otros, como teléfono o dirección de correo
electrónico, que no tienen por qué estar presentes y finalmente, una
tabla (la de empresas y trabajadores en ella) en la que sólo se han de
introducir datos si el usuario está trabajando.

Gracias a esto el alta de los usuarios es sencilla, como se muestra en
el listado 1. Si el usuario ha introducido el DNI, elemento que se
considera imprescindible, se insertarán los datos dados en la base de
datos. Si además se han introducido otra serie de datos (como son el
número de teléfono y la dirección de correo) se introducirán estos en
las tablas correspondientes.  Finalmente, si el usuario ha indicado
que está trabajando se le dirigirá a la segunda parte de la entrada de
datos.

*************** LISTADO 1 ***********************

Como se ve la entrada de los datos básicos no tienen gran
complicación, se podría hacer más compleja añadiendo comprobaciones de
tipos de datos antes de introducirlos, pero otras funciones, como la
detección de problemas de inserción no pueden "interceptarse" en
WWW-SQL. Es aquí donde vemos los primeros problemas y debilidades de
éste. Todo funciona bien si los datos de entrada son correctos y no se
encuentra con casos "extraños". Pero si se da cualquier problema, el
error se le mostrará directamente al usuario en la página HTML
devuelta, ya que no es posible "interceptarlo". En cualquier caso esta
implementación nos sirve como prototipo. Este tipo de errores sólo se
pueden mejorar si se reimplementa el interfaz en un lenguaje más
versátil que soporte más posibilidades.



La entrada de datos de empresas resulta algo más compleja. Cuando un
usuario se da de alta como trabajador y quiere indicar la empresa en
la que está trabajando y su puesto, pueden darse dos casos, el caso de
que la empresa no exista ya en la base de datos y sea el usuario el
encargado de introducir los datos de ésta, o el caso de que la empresa
ya exista y el usuario pueda sencillamente seleccionarla.

El interfaz que permite dar de alta estos datos tiene que contemplar
ambos casos. Se puede considerar que es el usuario el que tiene que
introducir siempre los datos de la empresa en la que trabaja.  Pero
entonces no podrá "ver" las empresas que ya están en la base de datos,
y se dará el caso de que existan múltiples personas que trabajan en la
misma empresa pero que no sea "la misma" a efectos de la base de
datos. Si sucede esto se está duplicando de forma innecesaria
información. También puede suceder que sólo se le deje al usuario
seleccionar una empresa de las ya existentes, con lo que se limita la
versatilidad del interfaz dado que tiene solicitar a alguien (quizás
al administrador) que dé de alta nuevas empresas para que pueda él
indicar en el interfaz que está trabajando en ella.

Por ello la opción elegida es la mostrada en el listado 2, en el que
la diferencia fundamental con respecto al formulario de entrada de
datos personales, es que parte del formulario se construye en base a
la información de la base de datos.

Así, por un lado el usuario introduce siempre información de su cargo
y departamento. Tiene que haber dos opciones:
\begin{itemize}
\item  seleccionar la empresa en la que está trabajando de una lista
de empresas en la base de datos, para ello genera la lista en tiempo
de ejecución de las que ya existen.
\item introducir los datos de una nueva empresa que no
esté en la lista mostrada.
\end{itemize}




************** LISTADO 2 *************************

Tras esto, como se muestra en el listado 3, se procederá a enviar los
datos a un programa encargado de tratarlos. Si el usuario ha
introducido una nueva empresa, ésta será introducida junto con sus
datos en la tabla correspondiente. Y, en cualquier caso, se
introducirá la información relativa del puesto y cargo que desempeña
la persona dentro de la empresa en la tabla que identifica las
relaciones laborales entre personas y empresas.

***************** LISTADO 3 **************************

Una mejora a estos formularios sería ofrecer la posibilidad de
realizar entre la lista de las empresas, por
ejemplo, búsquedas de cadenas o ser capaz de comprobar que una empresa
que se va a introducir se parece "sospechosamente" a otra ya
introducida (por ejemplo, porque sea el mismo nombre pero sin
acentos). Pero en principio el prototipo es suficientemente
funcional. En realidad se puedan hacer muchas mejoras para que luego,
en el uso diario, se evite que los usuarios introduzcan empresas
distintas que luego, realmente, son la misma.




\subsection{Autenticación.}

Para lograr limitar el acceso a la información contenida en la base de
datos, con el fin de mantener el propósito de la asociación, es
necesario que los usuarios sean autenticados antes de acceder a la
parte privada del servidor. No interesa que cualquiera pueda acceder a los datos generados de todos los miembros.

¿Cómo se puede saber si quién accede tiene derecho, o no, de consultar
los datos? Muy sencillo, sólo aquel que ya ha sido registrado puede
hacerlo por lo que se necesita realizar algún tipo de pregunta con la
que se puede saber que la persona que está accediendo ha sido
registrado previamente. Para hacer la pregunta se puede escoger parte
de la información utilizada en el registro, pero ha de ser de tal
manera que el que accede, al darla, está demostrando de forma
fehaciente su identidad.

Ésta no es la única posibilidad para solventar este tipo de
situación. Habitualmente, en los servidores con algún tipo de
autenticación de usuarios, se le da la posibilidad a éstos para elegir
un nombre de usuario y una clave que se introducen al registrarse. El
problema surge, sin embargo, cuando pasa mucho tiempo desde que  el
usuario se registró y vuelve a acceder. Dándose el caso,
frecuente, de que se haya olvidado la contraseña elegida y se tiene
que solicitar su envío. Por las condiciones del servicio que se va a
implementar es más que posible que se de éste tipo de situación, ya
que en principio no tiene mucho sentido realizar consultas diarias.

Para evitar este problema en el diseño planteado, se ha optado por
preguntar al usuario información que sólo éste conoce y no vaya a
olvidar con facilidad.

Si se estudia la información almacenada en la base de datos sobre cada
persona, se puede ver que hay sólo son algunos los campos que sólo
vaya a ser conocidos por el que acceder y no puedan estar sujetos a un
ataque por "fuerza bruta" (probar todas las combinaciones posibles
hasta encontrar una respuestas válida).

Sin embargo sí que se pueden escoger parejas de campos que sea más
improbable que puedan ser conocidas al mismo tiempo. Por ello se ha
elegido dentro del desarrollo que el usuario tenga que responder con
dos datos que va a conocer siempre y no olvidará fácilmente y que, por
otro lado, es difícil que otra persona pueda conseguir reunir.

Los datos escogidos han sido el DNI y la fecha de nacimiento. La
función del interfaz a la hora de autenticar será, por tanto,
solicitar éstos al usuario y comprobar si son correctos. Esto es, si
hay algún usuario en el que concuerden ambos valores, de forma que se
podrá saber quién ha sido el usuario registrado. Evidentemente, ningún
sistema de autenticación es perfecto y éste, también, será susceptible
de fallos.

En cualquier caso, queda aún pendiente establecer algún mecanismo para
que el servidor "sepa" que el usuario ha sido autenticado y no le
pregunte esta información cada vez que quiera acceder al área privada.

Hay por lo menos dos mecanismos para hacer éstos, y los dos derivan de
el hecho de que las transacciones a través del protocolo HTTP carecen,
en principio, del concepto de "estado":
\begin{itemize}
\item Autenticación basada en el servidor, en el que será éste el
encargado de gestionar las sesiones y autenticar debidamente a los
usuarios. Este tipo de autenticación se puede activar en Apache a
través de ficheros {\itshape .htaccess\/} con el módulo {\itshape mod\_auth\/}.
\item Autenticación basada en el cliente, en el que será éste el
encargado de enviar al servidor una "prueba" de que es un cliente
registrado.
\end{itemize}


Para facilitar el desarrollo se ha elegido éste último ya que es un
mecanismos que se integra muy bien con el esquema de base de datos
propuesto. De esta forma se puede encargar la base de datos de guardar
también la información relacionada con las sesiones si se desea.

Hay que destacar, sin embargo, que se podría llegar a utilizar
autenticación basada en el servidor si se utilizar un módulo de
autenticación que funcionara contra una base de datos relacional
(SQL). Existe una implementación de un módulo de este tipo que se ha
dejado de distribuir con Apache, ya que sólo ofrecía la posibilidad de
comunicarse con la base de datos Msql. Se está trabajando, sin
embargo, en una implementación genérica (módulo {\itshape mod\_auth\_sql\/})
para poder utilizar cualquier base de datos en el primer caso.






\subsubsection{Uso de {\itshape cookies\/}.}

La forma de establecer el mecanismo de autenticación en base a una
"prueba" que entrega el cliente es haciendo uso del concepto de
{\itshape cookies\/}.

Las {\itshape cookies\/} fueron una propuesta, inicialmente de Nestcape
Communications, para ser capaz de gestionar transacciones con estado
en el entorno WWW. El problema fundamental es que no se puede
implementar aplicaciones del estilo de "carrito de la compra" porque
en ningún lado se podía, en principio, almacenar información de lo que
ha hecho el usuario. Este tipo de sesiones deberían soportar, además,
que el cliente se desconectara y volviera un tiempo más adelante y
siguiera teniendo las mismas cosas seleccionadas "en el carrito".
Este mecanismo se especifica con detalle en el estándar de Internet
RFC 2109 del 27 de agosto de 1999.

Cada cliente puede guardar un número ilimitado de {\itshape cookies\/} que
no son más que pares de atributo-valor asignado a un dominio concreto
y que el cliente almacena, pudiendo guardar más información como
comentario, tiempo de vida, etc... El cliente, si tiene el soporte de
{\itshape cookies\/} activado, puede recibir éstas y, posteriormente,
deberá darlas cada vez que accede a un servidor dentro del dominio
indicado.

Es evidente, sin embargo que existe la posibilidad de ataques a este
sistema por parte de elementos que estén "escuchando" la comunicación
entre cliente servidor. Si pueden recoger la cookie podrían hacerse "pasar"
por otro usuario. Para esto hay dos soluciones: 
\begin{itemize}
\item Utilizar un protocolo seguro (un servidor https) de forma que el
intercambio de información entre cliente y servidor vaya cifrado y sea
difícil de interceptar.
\item cifrar la {\itshape cookie\/} e incluir información en ésta
relacionada con el ordenador que está accediendo (su dirección IP por
ejemplo). De forma que otro cliente no pueda interceptarla y usarla
con éxito.
\end{itemize}


En cualquier caso, aún a pesar de los problemas de autenticación, en
este prototipo se ha optado por  utilizar un esquema más sencillo en
el que el servidor va a entregar una {\itshape cookie\/} con un valor
determinado (en este caso el DNI) y va a "confiar" en el cliente que
tenga una {\itshape cookie\/} para el dominio donde está ubicado el
servidor de la base de datos con un contenido válido en este campo.

Como se puede ver en el listado 4, se hace una consulta a la base de
datos con los valores dados en el formulario ({\itshape dni\/} y
{\itshape fecha\/}) que son contrastados con la base de datos. Si existe
un usuario con estos mismos datos se le entrega entonces una
{\itshape cookie\/} a través de la página HTML (tag META: Set-Cookie y
Set-Cookie2, se utilizan ambos por compatibilidad).

********************* LISTADO 4 *************************

Una vez hecho esto se puede incluir una comprobación en cada página.
Ésta se asegura de que el usuario ha sido autenticado utilizando
el código mostrado en el listado 5.

********************* LISTADO 5 ************************






\subsection{Consultas}

Finalmente, es necesario implementar herramientas para que los
usuarios registrados puedan hacer uso de la información almacenada en
la base de datos. En realidad aquí hay muchas aplicaciones posibles,
pero las que primero se pueden pensar son:

\begin{itemize}
\item Generar una listas de personas registradas por año de promoción.
\item Generar un listín de las personas registradas con su teléfono y
dirección de correo electrónico.
\item Buscar una persona determinada en la base de datos.
\item Generar una lista de personas y empresas en las que trabajan.
\item Buscar información de las personas que están trabajando en una
determinada empresa.
\end{itemize}


No se van a explicar en detalle todas estas consultas, ya que el hecho
de implementarlas en general no es más que el realizar una consulta
SQL y mostrar los datos en una tabla. 

Por ello se va a mostrar sólo la segunda consulta, el "listín
telefónico" generado en base a los datos de la base de datos. Como se
puede ver en el listado 6 se hace un {\itshape select\/} cruzando tres de
las tablas de la base de datos para al final sacar un vector con la
información personal (nombre y apellidos) y de contacto (número de
teléfono y correo electrónico) de la base de datos.

********************* LISTADO 6 ************************

Como se puede ver en el listado lo que se hace es recoger un número
limitado de resultados (definido en la variable {\itshape step\/}) de la
consulta realizado y llamar a la función {\itshape print\_rows\/} para que
todos estos se impriman en una tabla HTML. El programa, además, es
capaz de llamarse a sí mismo incrementando la cuenta (offset, variable
{\itshape ofs\/}) para poder ir recuperando páginas sucesivas de
información de la consulta y así no tener que mostrar toda la consulta
de golpe.

Como se puede ver en el listado 7 esta misma filosofía de enseñar los
resultados de una consulta se puede aplicar a consultas cada vez más
complicadas, como puede ser el caso de buscar qué personas están
trabajando en una empresa determinada.



****************** LISTADO 7 ******************************






\section{Conclusiones}

Con este artículo se concluye la implementación de un acceso a una
base de datos a través de un interfaz WWW habiendo visto todos los
aspectos, al menos superficialmente (con las restricciones que pueda
tener una publicación como ésta), de diseño y desarrollo, así como las
alternativas posibles de implementación.

Este prototipo es, por supuesto, muy mejorable. Se han visto algunas
de las deficiencias de www-psql para tratar situaciones complejas,
como podía ser la entrada de datos. Este tipo de situaciones podría
evitarse añadiendo programación a los interfaces también en
Javascript, pero, en cualquier caso, siempre es necesario que el
servidor compruebe que los datos recibidos son correctos (no se puede
"fiar" de lo que le llega). Una alternativa más versátil y que podrá
enfrentarse mejor a este problema sería reimplementar el interfaz para
utilizar PERL embedido o PHP/FI. Ambos van a permitir tener un acceso
más transparente a la base de datos, al mismo tiempo que
posibilitarían la intercepción de errores y la comprobación de los
datos recibidos de una manera mucho más elegante.

En cualquier caso estos temas quedan pendientes para sucesivos
artículos. Baste decir que el desarrollo realizado del prototipo ha
sido un desarrollo real, que se encuentra en fase de pruebas, para
llevar a cabo este tipo de asociación de antiguos alumnos en una
Escuela de la Universidad Politécnica de Madrid. El código del
desarrollo está a disposición de las personas interesadas, contacte
con el autor si lo desea.

También quedaría pendiente la posibilidad de mejorar este servicio, ligándolo a una lista de correo. Esta lista puede servir de medio para comunicar a los distintos usuarios registrados. Puede ser util, por tanto, suscribir o desuscribirles en función de altas y bajas de la base datos. Asismismo, sería posible enviar un resumen periódico de altas y bajas de forma automática a dicha lista.




\section{Sumarios}



El servicio sirve como punto de encuentro.

WWW-SQL es un CGI que interpreta páginas web.

Un programador puede echar en falta estructuras complejas en WWW-SQL.

El servidor se divide en dos partes.

Se hace hincapié en el acceso a la base de datos.

La entrada de datos se hace a través de un formulario.

Se pueden implementar múltiples consultas útiles.

Aquí se completa la implementación del prototipo.

Se puede mejorar utilizando ePERL o PHP/FI.






\section{Listados}



LISTADO 1-
\begin{tscreen}
\begin{verbatim}
<HTML>
<HEAD>
<TITLE>Alta de usuario</TITLE>
<! sql if "$dni" == "">
<! sql print "Error: Debe dar un DNI">
<! sql setexpr alta 0>
<! sql else>
<! sql connect localhost jfs>
<! sql database exalumnos>
<! sql query "begin">
<! sql query "insert into persona (dni, nombre_persona, apellidos_persona , calle_persona, ciudad_persona, pais_persona, codigo_postal, graduacion, ingreso, fecha_nacimiento) values ( $dni, '$nombre', '$apellidos','$calle', '$ciudad', '$pais', '$codigo_postal', $fecha_grad, $fecha_ingreso, '?fecha_nac')">
<! sql query "end">
<! sql print "<META http-equiv=\"Set-Cookie\" content=\"dni="$dni;" path=/\">" >
<! sql print "<META http-equiv=\"Set-Cookie2\" content=\"dni="$dni;" path=/\">" >
<! sql if "$email" != "">
<! sql query "begin">
<! sql query "insert into usa_mail (dni, e_mail) values ( $dni, '$email')">
<! sql query "end">
<! sql endif>
<! sql if "$telefono" != "">
<! sql query "begin">
<! sql query "insert into usa_tfo (dni, telefono, prefijo) values ( $dni, '$telefono', '$prefijo')">
<! sql query "end">
<! sql endif>
<! sql setexpr alta 1>
<! sql if "$trabajo" == "y">
<! sql print "<META http-equiv=\"refresh\" content=\"1;URL=alta_empresa.html\">" >
<! sql endif>
<BODY>
<! sql if $alta == 1>
<! sql print "Su solicitud ha sido aceptada.">
<! sql if "$trabajo" == "y">
<! sql print "<A HREF=\"alta_empresa.html\">Dé de alta a su empresa</A>." >
<! sql endif>
<! sql close>
<! sql endif>
<! sql endif>
</BODY>
</HTML>
\end{verbatim}
\end{tscreen}




PIE LISTADO 1: Código para dar de alta a un usuario

LISTADO 2-
\begin{tscreen}
\begin{verbatim}
#use wml::exalumnos::plantilla title="Dé de alta su empresa" minititle="Alta empresa"
<H1>Dé de alta su empresa en la Base de Datos:</H1>
<BR>
<FORM METHOD="GET" ACTION="alta_empresa.pgsql">
Su puesto dentro de la empresa: <INPUT TYPE="TEXT" NAME="puesto"><BR>
Su departamento dentro de la empresa: <INPUT TYPE="TEXT" NAME="departamento"><BR>
<HR>

<protect>
<! sql connect localhost nobody >
<! sql database exalumnos >
<! sql query "begin" >
<! sql query "declare tmp cursor for select nombre_empresa from empresa" >
<! sql if $NUM_ROWS != 0 >
<! sql query "fetch all in tmp" q1 >
Busque su empresa: <SELECT NAME="empresa">
<OPTION VALUE="" DEFAULT>
<! sql print_rows q1 "<OPTION VALUE=\"@q1.0\">@q1.0">
</SELECT><BR>
<! sql endif >
<! sql free q1 >
<! sql query "end">
</protect>
<STRONG>Sólo si su empresa no está en la lista previa introduzca los datos de ésta:</STRONG><BR>

Nombre de la empresa: <INPUT TYPE="TEXT" NAME="nombre"><BR>
Dirección:
Calle: <INPUT TYPE="TEXT" NAME="calle"><BR>
Ciudad: <INPUT TYPE="TEXT" NAME="ciudad"><BR>
País: <INPUT TYPE="TEXT" NAME="pais"><BR>
Código postal: <INPUT TYPE="TEXT" NAME="codigo_postal"><BR>
Actividad: <INPUT TYPE="TEXT" NAME="actividad"><BR>
Número aproximado de empleados: <INPUT TYPE="TEXT" NAME="empleados"><BR>

<INPUT TYPE="SUBMIT" VALUE="Dar de Alta">
</FORM>
</BODY>
</HTML>
\end{verbatim}
\end{tscreen}




PIE LISTADO 2: Formulario para darse de alta en una empresa

LISTADO 3-
\begin{tscreen}
\begin{verbatim}
#use wml::exalumnos::plantilla title="Alta de su empresa" autorizacion
# aquí se usa la cookie que se ha puesto antes para poner el valor a
# trabaja_en empresa
<protect>
<! sql connect localhost  jfs >
<! sql database exalumnos >
<! sql query "begin" >
<! sql if $empresa = "" >
<! sql query "insert into empresa (nombre_empresa,
calle_empresa, ciudad_empresa, pais_empresa, codigo_postal,actividad, num_empleados)
values ( '$nombre', '$calle', '$ciudad', '$pais',
'$codigo_postal', '$actividad', $empleados )" >
<! sql else >
<! sql set nombre "$empresa" >
<! sql endif >
<! sql query "insert into trabaja_en (dni, nombre_empresa, puesto ,departamento)
values ( '$dni', '$nombre', '$puesto', '$departamento')" >
<! sql query "end" >
<! sql print "<H1>Solicitud aceptada</H1>">
<! sql print "<P>Se han registrados sus datos asi como los de la empresa en los que trabaja. "</P>>
<! sql print "<P>Gracias por darse de alta</P>.">
<! sql close>
</protect>
\end{verbatim}
\end{tscreen}






PIE LISTADO 3: Alta de una empresa

LISTADO 4-
\begin{tscreen}
\begin{verbatim}
<HTML>
<HEAD>
<TITLE>Acceso de usuario</TITLE>

<! sql setdefault dni 0 >
<! sql if $dni == 0 >
<! sql print "<META http-equiv=\"refresh\" content=\"1;URL=respuesta/rechazado.html\">" >
<! sql setexpr aceptado 0 >
<! sql else >
<! sql connect localhost nobody >
<! sql database exalumnos >
<! sql query "begin" >
<! sql query "declare tmp cursor for select * from persona where dni=$dni and fecha_nacimiento='?fecha'" >
<! sql query "fetch 10 in tmp" q1 >
<! sql query "end" >
<! sql free q1 >
<! sql if $NUM_ROWS != 0 >
<! sql print "<META http-equiv=\"refresh\"content=\"1;URL=respuesta/aceptado.html\">" >
<! sql print "<META http-equiv=\"Set-Cookie\" content=\"dni=$dni;path=/\">" >
<! sql print "<META http-equiv=\"Set-Cookie2\" content=\"dni=$dni;path=/\">" >
<! sql setexpr aceptado 1 >
<! sql else >
<! sql print "<META http-equiv=\"refresh\" content=\"1;URL=respuesta/rechazado.html\">" >
<! sql setexpr aceptado 0 >
<! sql close>
<! sql endif >
<! sql endif >

</HEAD>
<BODY>

<! sql if $aceptado == 0 >
<! sql print "Lo siento su petición ha sido <A HREF=\"respuesta/rechazado.html\">rechazada</A>." >
<! sql else >
<! sql print "Su petición ha sido <A HREF=\"respuesta/aceptado.html\">aceptada</A>." >
<! sql endif >

</BODY>
</HTML>
\end{verbatim}
\end{tscreen}




PIE LISTADO 4:  Autenticación de un usuario



LISTADO 5-
\begin{tscreen}
\begin{verbatim}
<! sql setdefault dni 0 >
<! sql if \$dni == 0 >
<H1>Error</H1>
<P>No conozco su DNI. Vaya a la <A HREF=\"$(USER)/alta.html\">página de altas</A> si aún no se ha dado de alta o a la <A HREF=\"$(USER)/acceso.html\">página de acceso</A> si no ha sido autentificado por el servidor.</P>
<protect>
<! sql else >
</protect>
\end{verbatim}
\end{tscreen}


PIE LISTADO 5: Autenticación del usuario en base a la cookie recibida.

LISTADO 6
\begin{tscreen}
\begin{verbatim}
#use wml::exalumnos::plantilla title="Listin de antiguos alumnos" autorizacion
<H1>Listín de antiguos alumnos</H1>
<protect>
<! sql connect localhost nobody >
<! sql database exalumnos >
<! sql setdefault ofs 0 >
<! sql setdefault step 10 >
<! sql query "begin" >
<! sql query "declare tmp cursor for select nombre_persona, apellidos_persona, telefono, e_mail  from persona, usa_tfo, usa_mail where persona.dni=usa_tfo.dni and persona.dni=usa_mail.dni order by apellidos_persona" >
<! sql if $ofs != 0 >
<! sql query "move $ofs in tmp" >
<! sql endif >
<! sql query "fetch $step in tmp" q1 >
<! sql if $NUM_ROWS != 0 >
<table>
<tr> <th>Nombre</th> <th>Apellidos</th> <th>Número de teléfono</th> <th>Correo electrónico</th></tr>
<! sql print_rows q1 "<tr> <td>@q1.0</td> <td>@q1.1</td> <td><CENTER>@q1.2<CENTER></td> <td>@q1.3</td></tr>\n" >
</table>
<! sql if $step-1 < $ofs >
<! sql print "<a href=\"listin.pgsql\?ofs=" >
<! sql eval $ofs - $step >
<! sql print "\">">Anterior</a>
<! sql else >
Anterior
<! sql endif >
<! sql if $NUM_ROWS = $step >
<! sql print "<a href=\"listin.pgsql\?ofs=" >
<! sql eval $ofs + $step >
<! sql print "\">">Siguiente</a>
<! sql else >
Siguiente
<! sql endif >
</center>
<! sql endif >
<! sql free q1 >
<! sql query "end" >
<! sql close >
</protect>
\end{verbatim}
\end{tscreen}




PIE LISTADO 6: Listín de los usuarios de la base de datos.

LISTADO 7-

\begin{tscreen}
\begin{verbatim}
#use wml::exalumnos::plantilla title="Búsqueda de antiguos alumnos en empresas" autorizacion
<H1>Búsqueda de antiguos alumnos en la empresa
<! sql print "$empresa">
</H1>
<protect>
<! sql connect localhost nobody >
<! sql database exalumnos >
<! sql setdefault ofs 0 >
<! sql query "begin" >
<! sql query "declare tmp cursor for select nombre_persona, apellidos_persona from persona, trabaja_en where persona.dni=trabaja_en.dni and strpos(upper(trabaja_en.nombre_empresa),upper('$empresa')) >0 order by apellidos_persona" >

<! sql if $ofs != 0 >
<! sql query "move $ofs in tmp" >
<! sql endif >
<! sql query "fetch 10 in tmp" q1 >
<! sql if $NUM_ROWS != 0 >
<table>
<tr> <th>Nombre</th> <th>Apellidos</th></tr>
<! sql print_rows q1 "<tr> <td>@q1.0</td> <td>@q1.1</td>\n" >
</table>
<br>
<! sql if 9 < $ofs >
<! sql print "<a href=\"busca_trabajadores.pgsql\?empresa=$empresa&ofs=" >
<! sql eval $ofs - 10 >
<! sql print "\">">Anterior</a>
<! sql else >
Anterior
<! sql endif >
<! sql if $NUM_ROWS = 10 >
<! sql print "<a href=\"busca_trabajadores.pgsql\?empresa=$empresa&ofs=" >
<! sql eval $ofs + 10 ><! sql print "\">">Siguiente</a>
<! sql else >
Siguiente
<! sql endif >
<! sql else >
<P>No se ha encontrado ningún trabajador de esa empresa</P>.
<! sql endif >
<! sql free q1 >
<! sql query "end" >
<! sql close >
</protect>
\end{verbatim}
\end{tscreen}




PIE LISTADO 7: Búsqueda de personas en empresas






\section{Capturas}



\begin{itemize}
\item Figura 1 - entidadrel.png  Pie: Esquema entidad relación del proyecto-
\label{entidadrel}
\item Figura 2 - esq-servidor.png. Pie: Esquema simplificado del
servidor a diseñar.
\label{esqservidor}
\item Figura 3 - cap-servidor.png. Pie: Página de alta de un usuario
en el servidor.
\label{capservidor}

\end{itemize}







\section{Notas de maquetación}



Por favor, el esquema entidad relación {\bfseries ha de verse},
en el número 14 no se leía nada de éste, por esto (y porque me han
llegado varios mails de queja al respecto) la vuelvo a incluir en este
artículo.




\section{Notas de coordinación}





\end{document}
