Interactividad,Forms & Scripts CGI [Primera Parte - Uso de los Forms]

[Segunda Parte - Programación de Scripts]

[Tercera Parte - Programación CGI avanzada]

Indice
------
PRIMERA PARTE
Introducción.
Cómo funciona la cosa.
Por donde empezar.
Forms.
Forms simples.
Text, Password y TextArea.
Radio Buttons.
Check Buttons.
Pop-up Lists.
Forms Multiples y el Reset Button.

SEGUNDA PARTE
Que necesitamos para empezar.
Qué son los scripts CGI?
Nuestro Primer Script.
Un script que hace Eco de un Form.
Un procesador de mensajes simple. (guestbook)
-retornar una página estática que no hallamos creado.
-verificar que todos los campos de un form sean completados
y que el email este correctamente especificado.
-Editar un documento HTML e insertar informacion en el mismo.
Puntos importantes al programar scripts.

TERCERA PARTE <<----

Imágenes clikeables.
Server-Side Image Maps.
Client-Side Image Maps.
Desempaquetando información.
Parsers CGI.
Locking de archivos.
Scripts avanzados.
Documentos Dinámicos.
Client Pull.
Server Push.
Mensajes MIME multipart.
Gif multiparts.
Counters.
Páginas Web con protección por password.
Que significa proteger una página.
El archivo .htaccess.
El archivo .htaccess.

Final del tutorial (por ahora).

Próximos desarrollos.
Apéndice: Librerías para la Programación de scripts CGI.
Sites con información acerca de CGI.
Vocabulario - Siglas.
Bibliografía.
S.Q
------------------------------------------------------------------------------

Imágenes clikeables.

A pesar que este tipo de elementos no está conectado directamente con los
scripts CGI pensé en incluirlos dado que también son una de las formas de
incrementar la interactividad entre el usuario y el web site.
Básicamente una imágen clikeable (es una acepción que inventé, ya fué la que
me pareció más correcta en castellano) es una imágen, un gráfico que cuando es
clikeada en alguna de sus partes envía las coordenadas X e Y de la posición del
mouse en ese momento y el server a partir de ellas genera un enlace con otras
páginas.
El uso más común de este tipo de imágenes es crear barras de herramientas
personalizadas, o regiones en un gráfico que permitan al usuario navegar hasta
un nuevo documento.

En teoría existen tres formas de lograr este tipo de imagenes;

+----------------------------------------------------------------------------+
¦Server-Side Image Maps (antigua) ¦
¦Es la forma más antigua, utilizaba un FORM para enviar la información y ¦
¦había que programar un script en el server que procesara dicha información. ¦
+----------------------------------------------------------------------------¦
¦Server-Side Image Maps (moderna) ¦
¦Es la forma más común y más ampliamente utilizada, utiliza el tag ISMAP y la¦
¦información es procesada por el web server. ¦
+----------------------------------------------------------------------------¦
¦Client-Side Image Maps ¦
¦Es la forma más moderna (y menos difundida) sólo soportada por los browsers ¦
¦en sus últimas versiones,y la información es procesada por el mismo browser.¦
+----------------------------------------------------------------------------+

Como todos los Web servers de la actualidad soportan la segunda forma,

descartaremos la revisión de la primera y comenzaremos directamente a usar el
tag ISMAP.

Partiendo de una imagen (un .GIF) elegiremos dentro de ella las áreas que
funcionarán como links a otros documentos.
Dichas áreas pueden ser definidas en base a uno o más de los siguientes
elementos.

RECT (x1,y1) (x2,y2) Determina un área rectangular en base a los vértices de

su diagonal principal.
CIRCLE (a,b,r) Determina un círculo de centro (a,b) y de radio r.
POLY (x1,y1) (x2,y2) .... (x1,y1) Determina un polígono cuyos vértices (x,y)
son dispuestos secuencialmente uno detrás de otro.

Almacenaremos estos elementos en un archivo que tendrá más o menos el

siguiente formato:
+----------------------------------------------------------+
¦ default /default.htm ¦
¦ RECTANGLE (475,157) (611,344) /principal.htm ¦
¦ RECTANGLE (233,182) (447,359) /buscar.htm ¦
¦ CIRCLE (130,54,20) /circulo.htm ¦
¦ POLY (46,27) (57,33) (58,23) (68,35) (46,27) /carita.htm ¦
+----------------------------------------------------------+

Usando un paquete gráfico cualquiera y revisando la posición del cursor

podremos construir este tipo de archivos, el único problema es que nos puede
resultar bastante tedioso el hacerlo "a mano".
Existe un freeware realmente excelente llamado MapThis! que hace todo el
trabajo por nosotros que puede ser bajado de cualquier repositorio de
shareware como OAK, Garbo, CICA, SimTel, etc..

Veamos entonces la estructura del archivo. La primera línea linkea el

documento que será cargado en caso de que no clikeemos en ninguna de las
áreas especificadas por los elementos que definimos. Si omitimos el tipo de
elemento el server tomará por default el RECT.
Por convención, grabaremos este archivo con la extensión .MAP en el directorio
que más nos convenga.

Cuando tengamos que poner el tag IMG correspondiente a la imagen en la página

en cuestión, agregaremos el parámetro ISMAP y haremos un hyperlink al .MAP de
esta manera.

<A HREF="/maps/dibujo.map"><IMG SRC="/images/barrita.gif" BORDER=0 ISMAP></A>

Entonces una vez cargada la página en nuestro browser, cada vez que clikeemos
en alguna parte de la imagen , el browser enviará las coordenas de la ubicación
en la que nos encontrabamos (esos numeritos que aparecen en la barra de status)
al server, y luego de esperar su proceso, éste último nos devolverá la
respuesta correspondiente.
Este mecanismo (Server-side), induce un cierto retardo (el proceso por parte
del server de nuestro pedido) por lo cual recientemente Netscape introdujo un
un nuevo mecanismo conocido como Client-Side Image Maps el cual veremos a
continuación.

Client-Side Image Maps.

En vez de realizar la conversión coordenadas/hyperlink en el server, esta
será realizada por el browser.
El .MAP que definíamos en el método anterior AHORA debe estar incluído DENTRO
del código HTML con el siguiente formato.

<MAP NAME="barradetareas">
<AREA SHAPE="RECT" COORDS="475,157,611,344" HREF="principal.htm">
<AREA SHAPE="RECT" COORDS="233,182,447,359" HREF="buscar.htm">
<AREA SHAPE="CIRCLE" COORDS="130,54,20" HREF="circulo.htm">
<AREA SHAPE="POLY" COORDS="46,27,57,33,58,23,68,35,46,27" HREF="acarita.htm">
</MAP>

Y el link en el tag IMG quedaría así:

<IMG SRC="/images/barrita.gif" USEMAP="#barradetareas">

En MAPNAME definimos el nombre del mapa y en USEMAP lo referenciamos.

Al probarlo podremos ver que en la barra de status no aparecen las coordenadas
sino directamente el nombre de la página en cuestion. Si utilizamos nombres
de página significativos esto puede ser de gran ayuda para el usuario.

Este método obviamente es mucho más rápido (no implica un intercambio de

información con el server) pero tiene la desventaja de que no está
implementado en todos los browsers todavía, a pesar de que está propuesto
como estándar para la definición de HTML 3.0.
Para cubrir este aspecto podemos utilizar los dos métodos simultáneamente
de esta manera.

<A HREF="/maps/dibujo.map">
<IMG SRC="/images/barrita.gif" USEMAP="#barradetareas" BORDER=0 ISMAP></A>

Si el browser no llegara a entender el USEMAP, procesará nuestro pedido en

base al link del ISMAP.

Desempaquetando información.

Aunque este tema puede resultar algo "técnico" creo que resulta interesante
incorporarlo al tutorial, ya que nos permite conocer el funcionamiento de esas
"cajas negras" que son las librerías, las cuales hemos utilizado al programar
nuestros scripts.
Sabemos que cuando usamos el método POST toda la información de un form es
"empaquetada" en una variable llamada QUERY_STRING, pero... en qué forma?

La variable QUERY_STRING puede almacenar solamente un string continuo sin

espacios, de manera que para enviar varios campos (y espacios) debe existir
algún tipo de codificación de los mismos.
De hecho, podemos verla en el siguiente ejemplo.
Supongamos que en nuestro form solicitamos los siguientes datos:
+----------------------------------+
¦Nombre: Sebastian ¦ (para variar :)
¦Edad: 22 ¦
¦Simpatizante de: Boca Juniors ¦ (que grande boquita:->
+----------------------------------+

Como decíamos estos datos deben ser empaquetados en un único string, esto se
hace poniendo un "&" (ampersand) entre cada variable y reemplazando cada
espacio por un signo "+", con lo cual conseguimos que la variable quede así;

+--------------------------------------------------------------+
¦QUERY_STRING = "nombre=Sebastian&edad=22&equipo="Boca+Juniors"¦
+--------------------------------------------------------------+

Adicionalmente, ciertos caracteres son reemplazados por su valor ASCCI en un

formato hexadecimal (%xx). Como vemos, esta ensalada de letras es imposible
de manejar tal como está, por lo tanto recurrimos a los "parsers" cuya función
es la de separar estos valores en cómodas y agradables variables.

Parsers CGI.
La rutina escrita para Perl es un poco (sólo un poco) más clara que su
correspondiente equivalente en C, por lo tanto la utilizaremos para la
explicación del funcionamiento de un parser.
Perl utiliza los llamados "arrays asociativos" que son muy similares
a los arrays que todos conocemos, excepto por la salvedad (y a la vez gran
ventaja) de que los índices no son númericos, sino alfanúmericos.
Cómo es esto ? En esta rutina, todos los campos que se separan son almacenados
en un array asociativo con el nombre @in. Si queremos acceder al contenido
del campo edad, por ejemplo, éste se encuentra en la posición "edad" y el
código empleado es el siguiente.
@in { 'nombre'};

Lo que sigue es la rutina &ReadParse (que figura en la líbreria "cgi-lib.pl"

de S.E.Brenner) comentada ampliamente para su mejor entendimiento.

+----------------------------------------------------------------------------+
¦# Perl Routines to Manipulate CGI input ¦
¦# [email protected] ¦
+----------------------------------------------------------------------------¦
¦# ReadParse ¦
¦# Lee datos envíados con POST o GET, los convierte a texto simple,y pone ¦
¦# un campo=valor en cada componente de la lista "@in" ¦
¦# También crea pares de campo/valores en %in, usando '\0' para separar ¦
¦# selecciones múltiples ¦
¦ ¦
¦sub ReadParse { ¦
¦ # Definición de las variables a utilizar. ¦
¦ local (*in) = @_ if @_; ¦
¦ local ($i, $loc, $key, $val); ¦
¦ ¦
¦ # De acuerdo al método de envío almacena en la variable $in el texto. ¦
¦ if ($ENV{'REQUEST_METHOD'} eq "GET") { ¦
¦ $in = $ENV{'QUERY_STRING'}; ¦
¦ } elsif ($ENV{'REQUEST_METHOD'} eq "POST") { ¦
¦ read(STDIN,$in,$ENV{'CONTENT_LENGTH'}); ¦
¦ } ¦
¦ ¦
¦ @in = split(/&/,$in); #separa en un array los contenidos de $in que se¦
¦ encuentran separados por "&" ¦
¦ ¦
¦ foreach $i (0 .. $#in) { ¦
¦ #Convierte los "+" en espacios. ¦
¦ $in[$i] =~ s/\+/ /g; ¦
¦ ¦
¦ # Separa el campo y su contenido . ¦
¦ ($key, $val) = split(/=/,$in[$i],2); # corta en el primer =. ¦
¦ ¦
¦ # Convierte %XX de números hexadecimales a alfanúmericos. ¦
¦ $key =~ s/%(..)/pack("c",hex($1))/ge; ¦
¦ $val =~ s/%(..)/pack("c",hex($1))/ge; ¦
¦ ¦
¦ # Asocia cada campo con su valor. ¦
¦ # usando \0 como separador de elementos múltiples(checkbox por ej) ¦
¦ $in{$key} .= "\0" if (defined($in{$key})); ¦
¦ $in{$key} .= $val; ¦
¦ ¦
¦ } ¦
¦ return 1; ¦
¦} ¦
+----------------------------------------------------------------------------+

Esta no es la única librería que existe para manejar CGI bajo Perl , pero
sí la más utilizada. Según el autor nuevas versiones incorporarán más
facilidades, tales como file uploading y otras.
Locking de archivos.

En la segunda parte de este documento planteé el hecho problemático de que dos

usuarios pretendan acceder al mismo tiempo a un mismo archivo, como es el caso
del mini-guestbook.
En Unix tenemos recursos que nos permiten realizar este tipo de bloqueos con
una llamada al sistema, pero bajo otros sistemas (y para mantener la "transpor
tabilidad" de nuestros scripts, veremos una técnica muy simple que puede ser
implementada en cualquier plataforma y que puede ser utilizada sin problemas.

Cuando dos usuarios quieren leer/escribir un mismo archivo (en realidad los
scripts llamados por ellos) se produce un conflicto, el de saber quien tiene
la prioridad al hacerlo. Una manera de resolver este conflicto es crear un
archivo "lock" cuya sola presencia nos indique que el archivo esta siendo
accedido en ese momento.
Así cuando nuestro script pretenda leer/escribir el archivo, primero consultará
la existencia del "lock", si existe esperará un segundo y volverá a intentar
y en caso de que no exista lo creará y procederá a la consulta.
Un ejemplo comentado en Perl nos mostrará esta técnica:

+-------------------------------------------------------------------+
¦$salir = 'no'; ¦
¦ while ($salir != 'si') { ¦
¦ if (-e "/mini-gb.lock") { ¦
¦ # Si el archivo existe, esperamos 1 segundo. ¦
¦ sleep(1); ¦
¦ } ¦
¦ else { ¦
¦ # Al no existir el archivo, lo creamos y empezamos el proceso.¦
¦ open(LOCK,">/mini-gb.lock"); ¦
¦ close LOCK; ¦
¦ . . . . . . . . .Proceso de nuestro script. . . . . . . . . ¦
¦ ¦
¦ # Destrabamos el archivo (lo eliminamos) ¦
¦ unlink("/guestlock"); ¦
¦ ¦
¦ #Salimos de nuestra rutina ¦
¦ $salir = si; ¦
¦ } ¦
¦ } ¦
+-------------------------------------------------------------------+

Scripts avanzados.
A partir de este punto analizaremos en detalle los requisitos para el manejo
de documentos dinámicos, profundizando en el conocimiento de la forma de
trabajo del protocolo HTTP y los mensajes MIME.

Documentos Dinámicos

Para introducirnos en el tema de los documentos dinámicos nos basaremos en una

aplicación práctica, la animación, es decir imagenes en movimiento sin dejar
de lado el hecho de que esta última es sólo una de las múltiples posibilidades
que nos brinda el manejo dinámico de la información.

Actualmente existen tres métodos (si incluimos el gif multipart) para poder
manejar información dinámicamente, en orden de eficiencia estos son;

+----------------------------------------------------------------------------+
¦Client Pull ¦
¦El server envía un "stream" de información, incluyendo una directiva (en la ¦
¦respuesta HTTP) que dice "vuelva a cargar estos datos en 5 segundos" o "vaya¦
¦y cargue esta URL en 10 segundos". Despúes de que se cumple el tiempo especi¦
¦ficado, el browser hace lo que se le indicó, o sea recargar la página actual¦
¦o conseguir una nueva página. ¦
+----------------------------------------------------------------------------¦
¦Server Push ¦
¦El server envía un "stream" de información y el browser la muestra, pero ¦
¦sigue manteniendo la conexión abierta; cuando el server lo requiera, puede ¦
¦continuar enviando más información para que el browser la muestre, y así ¦
¦sucesivamente.. ¦
+----------------------------------------------------------------------------¦
¦Gif multipart ¦
¦Se trata del método más avanzado (lo vieron en WebTV?) que utiliza un nuevo ¦
¦formato de imagen GIF en donde se incluyen múltiples cuadros separados por ¦
¦comandos de animación, los cuales pueden ser vistos con el browser de ¦
¦Netscape partir de la versión 2.0 ¦
+----------------------------------------------------------------------------+

Analicemos en detalle cada uno de los métodos.

Client Pull
Para muestra basta un botón, así que de entrada prueben el siguiente código;

<META HTTP-EQUIV="Refresh" CONTENT=1>

<TITLE> Primera página</TITLE>
<H1> HOLA! </H1>
Una demostracion de documentos dinamicos<P>

Y?? Qué pasó?, por el bien de este tutorial espero que el documento haya sido
recargado por el browser al pasar un segundo.

Esto lo logramos al agregar el tag "META" (el cual permite simular respuestas
HTTP en páginas HTML) que le dice al browser que el server le está enviando
un header con la indicación "Refresh: 1".
Cambiando el valor, cambiamos el tiempo de retardo obviamente.
Observemos que cada directiva "Refresh" es única y por tanto la página NO será
refrescada cada un segundo eternamente, sino una única vez y que al tratarse
de una respuesta HTTP (simulada) la misma debe figurar al comienzo de nuestra
página.
Otra cosa que podemos lograr con este tag es cargar otro URL luego de una
determinada cantidad de tiempo. La sintaxis es la siguiente:

<META HTTP-EQUIV="Refresh" CONTENT=10; URL=http://mimaq.midominio/dinamic.htm>

Que hará que el browser luego de diez segundos de haber cargado la primera
página vaya y traiga la que se encuentra referenciada por la variable URL.
Un detalle importante es que debemos utilizar URLs absolutos, es decir incluir
en la definición el "http://..." y no emplear URLs relativos.

Y que pasaría si hacemos lo siguiente:

+----------------------------------------------------------------------------+
¦pri.html ¦ seg.html ¦
+--------------------------------------+-------------------------------------¦
¦<META HTTP-EQUIV="Refresh" CONTENT=3; ¦<META HTTP-EQUIV="Refresh" CONTENT=3;¦
¦URL=http://mimaq.midominio//seg.html> ¦URL=http://mimaq.midominio//pri.html ¦
¦ ¦ ¦
+----------------------------------------------------------------------------+

Más de uno se habrá dado cuenta de que estos dos documentos se llaman el uno
al otro cada tres segundos, generando una especie de "loop" infinito.
A partir de este ejemplo, podemos inducir varias otras combinaciones tales
como la de un documento que se llame a si mismo cada 0 segundos provocando así
también este tipo de "loops sin fin".
O podríamos hacer una cadena más larga, como la que sigue;

Página 1 +
• Página 2 + Con la cual obtendríamos una especie
¦ Página 3 + de animación aunque por cierto,
¦ Página 4 + bastante pobre.
¦ Página 5
+---------------------------+

Un ejemplo de utilización práctica de esta técnica ocurre en aquellas páginas

que nos indican que la página original ha cambiado de lugar y que en cinco
segundos seremos automáticamente redireccionados a la nueva ubicación.

Server Push
En contraste con el Client Pull, este mecanismo aprovecha que el server puede
mantener una conexión abierta por un tiempo indefinido, dejando espacio para
que sean enviadas varias respuestas secuencialmente.
Para lograrlo se utiliza un tipo MIME experimental (nuevo, no registrado aún
como standard) llamado "multipart/x-mixed-replace".

Mensajes MIME multipart.

Existen varios tipos diferentes de mensajes "multipart"MIME. Cada uno de ellos
le indica al cliente como debe procesar las diferentes partes que le serán
enviadas.
Con el tipo "multipart/mixed", la información de cada parte es independiente
de las otras, y el cliente debería mostrar una tras otra a medida que van
llegando. Con el tipo "multipart/alternative", la información de cada parte es
idéntica, pero estan formateadas de una manera distinta de manera que el
cliente determina cual es el "mejor" formato que puede mostrar (por ejemplo
elige "rich text" en vez de plain text) y lo muestra.
Con el tipo "multipart/parallel", el cliente debería mostrar cada parte
simultáneamente, si le fuera posible.
Con el tipo "multipart/mixed-replace" que será el que utilizaremos, cada parte
del mensaje se superpone a la parte anterior; el cliente sobreescribe la
parte vieja con la más nueva.

Un mensaje MIME multipart está compuesto de un header y una o más partes que
componen la totalidad del mensaje. El header indica como deben ser procesadas
las distintas partes del mensaje y cuales son los separadores de las mismas,
como ejemplo;

Content-Type: multipart/x-mixed-replace;boundary=SeparaPartes

Cuando el cliente encuentra este tipo en el header, hace un refresh del sector
correspondiente cada vez que una nueva parte del mensaje llega,
sobreescribiendo de esta manera la anterior.

Cada parte del mensaje tiene su propio header, el cual indica el tipo de datos
que esa parte contiene, "plain text", un gráfico GIF o HTML por ejemplo.
El header de cada parte siempre se encuentra debajo del separador que
hallamos especificado (en la línea que vimos le pusimos "SeparaPartes" de
nombre al separador , pero podríamos haber utilizado cualquier otro).

El server indica el fin de un mensaje multipart enviando un separador con el

agregado de dos guiones, por ejemplo nuestro separador quedaría;

--SeparaPartes

El script que sigue es una version reducida del NPH 1.2 creado por Matt Wright
y en él veremos una implementación comentada del mecanismo que acabamos de
describir.
+----------------------------------------------------------------------------+
¦ #!/usr/bin/perl ¦
¦ # Variables ¦
¦ $veces = "1"; ¦
¦ $dirbase = "/WWW/images/animation/"; ¦
¦ @archivos = ("primero.gif","segundo.gif","tercero.gif","primero.gif"); ¦
¦ $tipo = "gif"; ¦
¦ ¦
¦ # Hacemos que el stream de datos fluya sin un buffer para hacerlo mas rapid¦
¦ select (STDOUT); ¦
¦ $| = 1; ¦
¦ ¦
¦ # Comienzo del contenido multipart. ¦
¦ print "Content-Type: multipart/x-mixed-replace;boundary=separador\n\n"; ¦
¦ print "--separador\n"; ¦
¦ ¦
¦ # Este for toma cada imagen de la secuencia, la envía, manda un separador ¦
¦ #y luego envía la siguiente, repitiendolo las veces que indique $veces. ¦
¦ for ($num=1;$num<=$veces;$num++) { ¦
¦ foreach $archi (@archivos) { ¦
¦ print "Content-Type: image/$tipo\n\n"; ¦
¦ open(GIF,"$dirbase$archi"); ¦
¦ print <GIF>; ¦
¦ close(GIF); ¦
¦ print "\n--separador\n"; ¦
¦ } ¦
¦ } ¦
+----------------------------------------------------------------------------+

Lo único que me quedaría por aclarar es que ya que el tipo "x-mixed/replace"

fué definido por Netscape, solamente funcionará con su browser versión 1.1 y
posteriores.

GIF multipart.

En este caso no tendremos que programar nada y es por lejos la forma más simple
de armar una animación, aunque mantiene la desventaja de ser visualizados
únicamente por el Netscape 2.0 en adelante.
En definitiva se trata de ampliar las posibilidades del formato GIF89A (aquel
que nos permite utilizar backgrounds transparentes).
Los archivos .GIF tienen al comienzo un "header" que indica su tamaño y otros
datos, con programas como el Gif Construction Set ampliaremos este header e
incluíremos líneas con la secuencia de imágenes y comandos de control.
El header de una animación simple quedaría de la siguiente manera:
+-----------------------------+
¦ HEADERGIF89AScreen(320x200) ¦
¦ LOOP ¦
¦ CONTROL ¦
¦ IMAGE320x200,256colours ¦
¦ CONTROL ¦
¦ IMAGE320x200,256colours ¦
¦ CONTROL ¦
¦ IMAGE320x200,256colours ¦
+-----------------------------+
Ya que el Gif Construction Set trae un help bastante completo y es sencillo
de usar no quisiera extenderme más en el tema.
Sugerencia: Leer con el GifCon los .GIF que trae de ejemplo.

Si nos decidimos por utilizar este método tengamos en cuenta lo siguiente.

La mayoría de los browsers (descartando Netscape 2.0) mostrarán únicamente el
primer cuadro de la animación y algunos pocos sólo el último.
De manera que si queremos que tratar de que la animación luzca bien en
cualquier browser, la solución más simple es hacer que el primer cuadro sea
el más presentable (nada de logos al revés;) y que el último sea igual al
primero.

Counters.

Implementar un "counter" no es una tarea muy díficil. Básicamente se graba en

un archivo el valor del contador, y cada vez que se hace un nuevo acceso a la
página controlada se lee este archivo, se incrementa en uno el valor leído y
se vuelve a grabar. Veremos un fragmento de script que hace esta tarea.
Por otro lado no quería dejar de comentar que existen scripts más complicados
que pueden generar una salida en la forma de un archivo .GIF. Estos scripts lo
que hacen es leer el valor a representar, "pegan" en una misma imagen los
dígitos que componen dicho número y la envían.
Si seguimos avanzando también encontraremos scripts que pueden controlar más
de una página, ya que trabajan en base a un archivo índice que almacena el
valor de los contadores para cada página en particular.
A los fines de este tutorial el ejemplo presentado es lo suficientemente
entendible como para poder implementarlo y practicar sin mucho trabajo.
+----------------------------------------------------------------------------+
¦ #!/usr/local/bin/perl ¦
¦ ¦
¦ open(CONTADOR,"$counter.dat") || die "Error al abrir el archivo: $!\n"; ¦
¦ $contador = <CONTADOR>; ¦
¦ close(CONTADOR); ¦
¦ if ($contador =~ /\n$/) { ¦
¦ chop($contador); ¦
¦ } ¦
¦ ¦
¦ $contador++; ¦
¦ ¦
¦ print "<HTML><HEAD><TITLE>Bla,bla,bla..</TITLE></HEAD>" ¦
¦ ¦
¦ open(CONTADOR,">$counter.dat") || die "Error al cerrar el archivo: $!\n";¦
¦ print CONTADOR "$contador"; ¦
¦ close(CONTADOR); ¦
+----------------------------------------------------------------------------+

Páginas Web con protección por password.

Para no dejar de lado el tema de la seguridad abordaremos el uso de passwords

en el acceso a un servidor Web.
Necesitaremos nuevamente tener algunos conocimientos previos, en este caso del
manejo de archivos UNIX.
Si utilizamos otro tipo de plataforma para correr el Web Server, como Windows
NT, tendremos este tema solucionado con una muy sencilla configuración a través
del uso de menúes (por lo menos con el Website).
Lo principal para aclarar antes de comenzar es que cuando utilizamos este
sistema (según su mecanica interna) restringimos el acceso a un directorio,
no a una página en particular.

El método se basa principalmente en poner en cada directorio a proteger un

archivo de nombre ".htaccess" que contiene los parámetros de configuración de
la protección implementada y el nombre del archivo que contiene las passwords
que normalmente es el ".htpasswd".

Y se acabó el misterio. Eso es todo. Cuando se le solicita al server una

página que tiene en su mismo directorio un ".htaccess", éste se encarga de
enviar los códigos HTTP necesarios para que el browser levante la ventanita de
autentificación.
Para explotar este recurso completamente pasaremos a analizar en detalle los
parámetros que pueden ser utilizados en el ".htaccess" y la forma en que
podemos mantener actualizado el ".htpasswd" .

El archivo ".htaccess".

Este archivo debe estar ubicado en el directorio que se desea proteger y dicha
protección afectará a todos los subdirectorios del mismo, a menos que posean
sus propios archivos ".htaccess".
Dado que se trata de un archivo de texto común podremos actualizarlo con
cualquier editor del que dispongamos.

+-----------------------------------------------+
¦ AutUserFile .htpasswd ¦
¦ AuthGroupFile /dev/null ¦
¦ AuthName Ingrese su user ID y su password. ¦
¦ AuthType Basic ¦
¦ ¦
¦ <Limit GET> ¦
¦ require user usuario1 usuario2 usuario3 ..... ¦
¦ </Limit> ¦
+-----------------------------------------------+

Descripción de los Parámetros.

AutUserFile: es el nombre del archivo que contiene los nombres de los

usuarios (users ID) y sus respectivas passwords. Este archivo debe estar
ubicado en el mismo directorio que ".htaccess" pero puede llevar cualquier
nombre. Por convención le daremos el nombre de ".htpasswd" .

AuthGroupFile: Este es el nombre del archivo de grupo. Podemos setear

grupos de usuarios para que tengan acceso a un directorio, en el caso del
ejemplo no tenemos un archivos de estos armado, por lo que direccionamos
a null que significa que no existe ningún archivo de grupos.

AuthName: Es el string que aparecerá en la ventanita que levanta el browser,

cuando se le pregunte al usuario su ID y su password.
AuthType: es la clase de seguridad que implementamos. "Basic" significa
Autentificación Básica HTTP, es decir que la información enviada a través de
la red NO será encriptada sino que será "uuencodeada" (uuencoded), lo cual
nos da un nivel de protección similar al de una sesión de telnet.
Existen otro métodos además de éste tales como PEM, PGP, Kerberos V5 y Digest.

En el ejemplo que vimos solamente el método GET está restringido usando la

directiva <Limit>. Para limitar otras métodos (particularmente en los
directorios CGI-BIN) se puede especificar los mismos separados por espacios
dentro de la directiva LIMIT. Por ejemplo:

<Limit GET POST PUT>

require user usuario1 usuario2 usuario3 .....
</Limit>

El comando "require" le dice al server cuales son los usuarios que están
autorizados en ese directorio. Este comando puede tomar dos formas, "require
user" para limitar el acceso según usuarios o bien "require group" para
limitar el acceso según grupos de usuarios.
Existen otros comandos que pueden ser implementados en este nivel, como
"allow" y "deny" que permiten otorgar o denegar (respectivamente) el acceso
a un dominio en particular.

<Limit GET POST PUT>

order deny,allow
deny from all
allow from .mecon.ar
</Limit>

Restringiedo el acceso a los documentos de ese directorio a aquellas máquinas

que se encuentren en el dominio .mecon.ar y excluyendo a las restantes.
Cabe destacar que los ID utilizados son completamente arbitrarios (es decir no
tienen relación con los usuarios del server).

El archivo .htpasswd .
Este archivo consiste en una lista de los user ID y sus password encriptadas,
es un archivo de texto común por lo que puede ser movido, copiado o borrado
como cualquier otro.

Por ejemplo:

pedro:WkSK1DE7N8.9.
pablo:hQty39EV1.g56
diego:JeB31vf9PSTgw
susana:EDRfRrfrw43q

Como no podemos crear una password encriptada "a mano" usaremos una herramienta
llamada htpasswd que permite construir este tipo de archivos.
Esta herramienta se usa de la siguiente manera:

Server> htpasswd -c .htpasswd USUARIO

Adding password for USUARIO
New password:********
Re-type new password: *******

Si queremos modificar la password de USUARIO en otro momento usamos la misma

sintaxis. Para eliminar usuarios simplemente se borra la línea correspondiente
dentro del archivo.

Proteccion a nivel de grupo

Cuando tenemos un gran número de usuarios que mantener podemos facilitar el
manejo de los mismos separándolos en "grupos" creando un archivo de nombre
".htgroup" (por convención) con el siguiente formato:

nombregrupo1: primeruser segundouser .... últimouser

nombregrupo2: primeruser segundouser .... últimouser
nombregrupo3: primeruser segundouser .... últimouser
y debemos cambiar el require por un "require group nombregrupo ".

Final del tutorial (por ahora).

Con el tema de las "passwords" damos por terminada la tercera parte de este
documento, lo que sigue es un apéndice con links que me fueron bastante útiles
al momento armarlo, la bibliografía utilizada y algo de vocabulario.
Terminar esta tercera parte fué algo más que un triunfo, (pensar que había
planeado tenerla lista para fines de marzo:), cada vez que agarraba el doc
surgía un tema nuevo, y así.
Releyendo las otras partes me doy cuenta que faltan algunos ítems (oh no..más
laburo :P) o que por lo menos están un poco incompletos, paciencia en cuanto
pueda sale una nueva versión corregida y aumentada.
Lo próximo que tengo en mente en cuanto a tutorials estará basado en el uso de
frames y JavaScript en páginas HTML, una tecnología interesante pero no madura
del todo en este momento, así como también una mini-introducción al lenguaje
Perl, de manera que en algunos meses más empezaré por ese lado.
A propósito, ustedes notarán que desde que empezó esto del tutorial mis
preferencias programáticas han ido cambiando a lo largo del tiempo.
Estos cambios tienen su fundamento; Perl es portable, es fácil de usar y de
aprender, es freeware y además es interpretado de manera que el ciclo edición/
testeo se hace mucho más corto.
Escribir este tutorial fué una tarea bastante grata, aprendí muchísimo tratan
do de explicar algunos conceptos,y como siempre para hacer de esta una tarea
completa espero sus comentarios (de los buenos y de los otros ;), en mi email:
[email protected] ,los cuales serán de gran ayuda en mis proyectos futuros.

Suerte y buenos scripts!

(frase afanada de algún lado)
Sebass.

Próximos Desarrollos.
El protocolo HTTP y HTTP-NG.
Meta Tags y su uso ( y abuso).
CGI scripts en otros lenguajes (Visual Basic por ejemplo)
HTML/CGI como front/end de nuestros programas.
Introduccion a Java y JavaScript.
Introduccion a Perl y aplicaciones CGI.

PD: Parece que no puedo dejar de escribir, no quería dejar de comentar que las
versiones HTML y Word del tutorial estarán disponibles en breve.

--
APENDICE: Librerías para la Programación de scripts CGI.

Estos son los URL de las librerías utilizadas en los ejemplos de este documento.

Librería C ----> UnCGI ----> http://www.hyperion.com/~koreth/uncgi.html

Librería Pascal ----> TPWCGI ----> http://141.2.61.48/tpwcgi/tpwcgi.htm
Librería Perl ----> CGI-LIB.PL ----> http://www.bio.cam.ac.uk/cgi-lin/1.14/cgi-lib.pl.txt

Sites con información acerca de CGI.

Estos sites contienen mucha de la información que fué utilizada para crear
este documento y son realmente muy interesantes.

http://shani.net:80/~tls/guide/index.html
http://www.stars.com/Vlib/Providers/CGI.html
http://super.sonic.net/ann/delphi/cgicomp/detail.html
http://www.city.net/win-httpd/httpddoc/wincgi.htm
http://www.aspectse.com/Product/dbWeb/dbWeb.html
http://128.172.69.106:8080/cgi-bin/cgis.html
http://users.aol.com/thingtone/workshop/index.htm

Vocabulario - Siglas.
URL: Universal Resource Locator
Una nomenclatura que describe en forma compacta la ubicación de cada
recurso en la Internet y el protocolo utilizado para acceder al mismo.

MIME: Multipurpose Internet Mail Extensions

Una nomenclatura que permite identificar correctamente el tipo de
datos que se esta enviando a través de una conexión.

HTML: HyperText Markup Languaje

Un lenguaje para el "armado" de documentos de hypertexto incluyendo
"links" y algunas otras caraterísticas adicionales.

CGI: Common Gateway Interface

Un mecanismo que permite a los browser de Web ejecutar programas en el
server Web y recibir la "salida" de estos programas.

HTTP: HyperText Transport Protocol

Un protocolo para la transferencia de documentos de hypertexto y otro
tipo de archivos.

VRML:Virtual Reality Modeling Languaje

Un lenguaje que mediante "modelos" permite generar visiones 3D de un
universo con "links" y otras características adicionales.

Bibliografía.

An exploration of Dynamic Documents - Netscape Corporation.

Very Limited Guide to HTML - Kevin Werbach.
CGI tutor - Bex Lanner.
HTML-based Interfaces - Nik Swoboda.
CGI Tutorial - Agora.
An guide to HTML and CGI scripts - Mike Smith.
Mosaic User Authentication Tutorial - NCSA.
Web Page Password Protecion - CNC.

FIN DE LA TERCERA PARTE - FIN DEL TUTORIAL

-----------------------------------------------+ 01/05/96
+--------------------------------------------+ ¦Sebastián Quiroga.
¦Este documento puede ser reproducido en su ¦ ¦
¦totalidad o en parte siempre que se conserve¦ ¦Email:
¦esta postdata o bien se haga clara mención ¦ ¦ [email protected]
¦de la fuente. ¦ ¦ [email protected]
+--------------------------------------------+ +------------------------------
+-------------+
¦Versión: 1.00¦
+-------------+