CGI´s

Un CGI (Common Gateway Interface) es un programa que se ejecuta en el servidor por petición del navegador de un usuario. El CGI produce un resultado, el cual se envía al navegador que provocó la ejecución del programa. Los CGI dan dinamismo a la web. Las páginas web puras (archivos HTML) son archivos de texto y por tanto estáticos. Sin embargo, si en lugar de pedir una página web el navegador ejecuta un programa, éste puede generar la página "al vuelo" y decidir en el momento cómo va a ser la página.

Por ejemplo, imagine una página web que muestre la hora como texto. Está claro que no se puede poner la hora con el editor de páginas web, ya que cada vez que alguien vea la página la hora será distinta. La solución es crear un programa que se ejecute cada vez que alguien quiera ver la página. El programa genera la página web en el momento en que se ejecuta y así coloca la hora correcta. Por ello los CGI añaden dinamismo a las páginas web.

En principio los CGI se pueden realizar con cualquier lenguaje de programación, ya que pueden ser ejecutables (archivos .exe). Sin embargo, lo más recomendable es utilizar un lenguaje de script con facilidades para realizar CGI. Nos referimos al Perl.

La ventaja del Perl es que por su forma y por las bibliotecas y utilidades de que dispone, es ideal para la realización de CGI's. Es más, a ello debe el enorme auge que ha tenido últimamente, aunque en un principio fue diseñado como lenguaje de propósito general.

Si no conoce el Perl, pero sí otros lenguajes más populares como el VisualBasic o JavaScript, nuestra recomendación es que utilice el ASP (Active Server Pages) para programar aplicaciones de servidor. Si conoce el Perl, también es recomendable utilizar ASP con PerlScript. La ayuda de los CGI preinstalados se encuentra en la guía del Webmaster., dentro de nuestra sección de Soporte de Productos.

El directorio cgi-bin

Los CGI no pueden ser colocados en cualquier directorio y esperar que funcionen. Un CGI ha de estar en un directorio que tenga permisos de ejecución de scripts, si se trata de un script en Perl, o de ejecución de archivos exe (que incluye scripts) si se trata de un ejecutable.

El directorio cgi-bin es el único por defecto preparado para admitir CGI. Dispone de permisos de ejecución y tiene eliminados los permisos de lectura y listado para proteger mejor las fuentes. Normalmente colocará ahí sus propios CGI. Si aún así desea colocar CGI propios en otros directorios, puede hacerlo siempre que les asigne los permisos adecuados. Eso lo puede hacer mediante el panel de control en la sección de Permisos.

El permiso de escritura

Muchos de los CGI en Perl que están disponibles en Internet o que usted pueda crear, desearán escribir datos en archivos de texto u otro tipo de bases de datos. Sin embargo, por defecto no hay ni un solo directorio público en la web con permisos de escritura. Deberá asignarlos mediante el panel de control.

La recomendación es que sus archivos de datos residan en el directorio Data, que está fuera de la web, aunque puede ser leido por los CGI. De esa forma evitará que cualquiera pueda leer sus archivos de datos desde la web. El directorio Data ya tiene los permisos de escritura, de forma que no deberá hacer nada especial si sigue esta recomendación.

De todas formas, hay CGI disponibles freeware (gratis) en Internet que escriben en archivos que se encuentran en el mismo directorio del script. Esta es una práctica poco recomendable. Para que estos CGI funcionen es necesario que al directorio en el que se encuentran se le asignen permisos de ejecución y de escritura simultáneamente. Y esto constituye un importante agujero de seguridad para su sitio web.

El Perl y Windows NT

Nuestros servidores funcionan sobre el sistema operativo Windows NT. Una de las ventajas del Perl es que al ser interpretado es muy portable. Sin embargo, tiene límites. Hay funciones de la biblioteca estándar que sólo existen en sistemas Unix y no en Windows NT. Debe tener esto en cuenta, y que no se puede garantizar que los scripts en Perl que encuentre en Internet vayan a funcionar sin cambios en Windows NT. Hay algunos que sí, pero normalmente es porque están diseñados con idea de portabilidad desde el principio.

Además, los CGI de terceros casi siempre requieren una adaptación previa (customize) para que funcionen. El motivo es que suelen depender de parámetros como rutas de directorios, nombres de archivos, etcétera. Por suerte, la zona de customización suele estar clara en la mayoría de los scripts, y consiste simplemente en cambiar valores de ciertas variables. La versión de Perl for Win32 de que disponemos es la de Active State, y procuramos que esté actualizada.

Tenga en cuenta los siguientes puntos si piensa utilizar scripts en Perl que están escritos para Unix:

En Unix, el intérprete de un script se lanza según la información de la primera línea, mientras que en Windows NT es según la extensión del archivo. Por ello, todos los scripts CGI en Perl deben llevar la extensión .pl y no la extensión .cgi.

En Windows NT no existe el comando MAIL que envía archivos por email mediante una tubería. Aquí es necesario utilizar Blat (vea más adelante la sección dedicada a él).

El servidor Web de Microsoft (IIS) es "Non parsed header" (NPH), lo que significa que cuando ejecuta un CGI no envía ninguna cabecera. Muchos scripts para UNIX asumen que el servidor web enviará la cabecera, por lo que tal vez deba retocarlos. Los envíos de información deberían comenzar de esta forma (o con otra cabecera):

print "HTTP/1.0 200 OK\n";
print "Content-type: text/html\n\n";

El módulo de biblioteca CGI.pm resuelve estos problemas de forma elegante (ver más adelante).

¿Por qué no funcionan los CGI?

La experiencia dice que en la gran mayoría de los casos es por culpa de los permisos. Si el CGI intenta hacer algo para lo que no tiene permiso (mayormente, escribir algún dato), terminará silenciosamente. Otra causa de los problemas puede ser la extensión del archivo (tiene que ser .pl y no vale .cgi). Asegúrese de que el script no utiliza características de Unix que no estén en Windows NT, como el MAIL.

Otra fuente de problemas son las rutas de directorio. En Unix se escriben de la siguiente forma:

$mypath = '/usr/bin/mydir';

Sin embargo, en Windows NT hay que usar el separador de directorios \ y comenzar las rutas absolutas por la letra de unidad. Es decir, la ruta anterior podría quedar de esta forma:

$mypath = 'c:\usr\bin\mydir';

Suponiendo que existiese el directorio c:\usr. Hay muchos directorios estándar en Unix que no existen en Windows NT. Cuando utilice rutas de este tipo tenga mucho cuidado con el tipo de comillas que utiliza para la cadena. Si utiliza comillas dobles (a veces es necesario si el path utiliza una variable) entonces debe utilizar \\ para evitar la interpolación. Nuestro ejemplo quedaría de la siguiente forma con comillas dobles:

$mypath = "c:\\usr\\bin\\mydir";

Las rutas relativas pueden ser problemáticas en Windows NT. Le recomendamos para mayor seguridad que utilice siempre rutas de directorio absolutas. Pregunte en soporte@webdominio.com cuál es la ruta de su Servidor Virtual. Piense en las sentencias de su script que escriben en archivos o leen de ellos como las mayores candidatas a provocar el error. En Windows NT no es necesario saber la ruta del intérprete Perl. Basta con que el script tenga la extensión .pl para que el servidor web encuentre y lance el intérprete de Perl.

Hay veces que el navegador nos juega malas pasadas porque cachea un mal funcionamiento del script y nos da un error sin intentar comunicar con el servidor. Esto puede localizarse por la rapidez con la que el navegador nos da el error. Se recomienda tener a mano los dos navegadores (Explorer y Netscape) y alternarlos para ver si el problema es igual en ambos. En ciertas ocasiones un navegador se empeña en seguir mostrando error cuando el problema ya está resuelto.

El problema de programar CGI es lo dificil que resulta la fase de depuración. Para depurar un script que no funciona le recomendamos:

Paciencia. Esto es lo más importante.

Escribir sentencias print por doquier para examinar valores de variables.

Comentar sentencias hasta que funcione, y luego ir descomentándolas una a una hasta encontrar la que hace fallar el script.

Blat.exe (envío por correo desde los scripts)

La utilidad freeware Blat.exe es un programa que envía correo electrónico, y que funciona con opciones desde la línea de comandos, por lo que es ideal para ser utilizado desde scripts. El modo de funcionamiento es básicamente el siguiente:

El mensaje que se quiere mandar por correo debe estar guardado en el disco duro. Por ello, normalmente guardaremos un temporal con el mensaje.

Invocamos a blat con los parámetros necesarios. Por ejemplo:

system ("blat.exe archivo -t usuario@dominio.com -f desde@dom.com -s \"El asunto\" ");

Borramos el archivo temporal.

Con la versión de Blat de que disponemos en el momento de escribir estas líneas (la 1.8.6b), las opciones disponibles son las siguientes:

Blat <filename> -to <recipient> [optional switches (see below)]
Blat -install <server addr> <sender's addr> [<try>[<port>[<profile>]]] [-q]
Blat -profile [-delete | "<default>"] [profile1] [profileN] [-q]
Blat -h [-q]
-install <server addr> <sender's addr> [<try n times> [<port> [<profile>]]]
: set's SMTP server, sender, number of tries and port for profile
(<try n times> and <port> may be replaced by '-').
<filename> : file with the message body ('-' for console input, end with ^Z)
-to <recipient> : recipient list (also -t) (comma separated)
-tf <recipient> : recipient list filename
-subject <subj> : subject line (also -s)
-f <sender> : overrides the default sender address (must be known to server)
-i <addr> : a 'From:' address, not necessarily known to the SMTP server
-cc <recipient> : carbon copy recipient list (also -c) (comma separated)
-cf <file> : cc recipient list filename
-bcc <recipient> : blind carbon copy recipient list (also -c)(comma separated)
-bf <file> : bcc recipient list filename
-organization <organization>: Organization field (also -o and -org)
-body <text> : Message body
-x <X-header: detail> : Custom `X-´ header. eg: -x "X-INFO: Blat is Great!"
-r : Request return receipt.
-d : Request disposition notification.
-h : displays this help.
-q : supresses *all* output.
-debug : Echoes server communications to screen (disables `-q´).
-noh : prevent X-Mailer header from showing homepage of blat
-noh2 : prevent X-Mailer header entirely
-p <profile> : send with SMTP server, user and port defined in <profile>.
-server <addr> : Specify SMTP server to be used. (optionally, addr:port)
-port <port> : port to be used on the server, defaults to SMTP (25)
-hostname <hst>: select the hostname used to send the message
-mime : MIME Quoted-Printable Content-Transfer-Encoding.
-enriched : Send an enriched text message (Content-Type=text/enriched)
-html : Send an HTML message (Content-Type=text/html)
-uuencode : Send (binary) file UUEncoded
-base64 : Send (binary) file using base64 (binary Mime)
-try <n times> : how many time blat should try to send. from '1' to 'INFINITE'
-attach <file> : attach binary file to message (may be repeated)
-attacht <file>: attach text file to message (may be repeated)
Note that if the '-i' option is used, <sender> is included in 'Reply-to:'
and 'Sender:' fields in the header of the message.
Optionally, the following options can be used instead of the -f and -i
options:
-mailfrom <addr> The RFC 821 MAIL From: statement
-from <addr> The RFC 822 From: statement
-replyto <addr> The RFC 822 Reply-To: statement
-returnpath <addr> The RFC 822 Return-Path: statement
-sender <addr> The RFC 822 Sender: statement
For backward consistency, the -f and -i options have precedence over these RFC 822 defined options. If both -f and -i options are omitted, then the RFC 821 MAIL FROM statement will be defaulted to use the installation-defined default sender address.