Notas para "El CGI Hecho Realmente Fácil"
Notas para "El CGI Hecho Realmente Fácil"
| De regreso a la Página Principal | Ir a Otros Tutoriales |
A petición, aquí hay algunos programas CGI "hola, mundo" para que comiences. La versión simple demuestra la salida CGI solamente, y la larga desplegará cualquier campo de entrada que le des. Ambas versiones en Perl y C están disponibles con fuente.
De regreso al principio de la página
Uno de los usos más comunes de un script CGI es enviar por correo datos a una dirección de email. Así que aquí está un simple script que hace precisamente eso, escrito en Perl, llamado mailer.pl.
Haz estos cambios al script antes de ponerlo en su lugar:
Existe una forma bastante pobre de enviar por correo datos de una forma que solamente usa HTML: en la etiqueta <form>, fija el atributo action a "mailto:" URL, y el atributo enctype a "text/plain". La mayoría de los navegadores manejan esto correctamente, por ejemplo, enviar datos en un mensaje de correo. Por ejemplo,
<form action="mailto:me@myhost.com" enctype="text/plain">
Existen desventajas: no puedes controlar el formato del texto enviado, y no puedes enviar una respuesta de regreso al usuario. Asímismo no todos los navegadores soportan este estilo de etiqueta <form>.
De regreso al principio de la página
Piensa en esto-- un script CGI es un programa que cualquiera en el mundo puede ejecutar en tu máquina. De acuerdo con esto, busca agujeros de seguridad cuando escribas tu script.
Sobre todo, no confíes en la entrada del usuario. En particular, no incluyas la entrada del usuario en un comando sin verificar cuidadosamente esa entrada, le permite a un hacker manejar un camión virtual a través de tu agujero de seguridad.
Digamos que tienes un programa CGI que permite al usuario ejecutar un "finger" en tu host. Ese script Perl podría tener una línea como
system "finger $username" ;
Pero si un usuario malicioso escribe "james; rm -rf /" como nombre de usuario, tu programa correrá
que borrará tantos de tus archivos como sea posible, lo cual probablemente no es lo que querías. Así que verifica que el nombre de usuario sea válido con algo comosystem "finger james; rm -rf /" ;
o usa una forma diferente para el comando system:$username!~ /[^\w.-]/ || die "Whoa! Buen intento amigo." ;
system("finger", $username) ;
Es fácil para un hacker enviar cualquier variable de forma a tu script con cualquier valor (aún caracteres no imprimibles). Tu seguridad no debería descansar en campos teniendo ciertos valores, ya sea que existan o no.
De regreso al principio de la página
Diferentes servidores Web se configuran de manera diferente. Algunos te permiten poner scripts CGI en el mismo directorio que tus páginas Web, con nombres de archivo terminando con ".cgi". Otros servidores te obligan a poner todos los scripts CGI en un directorio específico, usualmente llamado "cgi-bin". Tu webmaster tiene la respuesta.
Necesitas fijar los permisos adecuados para el archivo de programa. En Unix el servidor Web (como cualquier otro proceso) corre bajo algún nombre de usuario. Tu programa CGI debe ser ejecutable para ese nombre de usuario, además de poder ser leído si es un script Perl o un shell script. En Unix, fija los permisos correctos con "chmod 750 *.cgi" (o "chmod 755 *.cgi", si tu servidor no tiene accesos de grupo a tus archivos-- intenta ambos, o pregunta a tu webmaster).
Si tu script no corre:
De regreso al principio de la página
Si tu respuesta HTML siempre es la misma, o si quieres responder con uno de los archivos existentes, puedes encontrar útil el encabezado de respuesta "Location:". Úsalo para redireccionar el navegador a otro URL.
Como ejemplo, si tu script CGI escribe la siguiente línea a STDOUT:
Location: response.htmlseguida de una línea en blanco, entonces el navegador remoto obtendrá a response.html y lo tratará como respuesta de tu script CGI. Puedes redireccionar al navegador a un URL ya sea relativo o absoluto.
En esta situación, no imprimas el encabezado de respuesta "Content-type:".
De regreso al principio de la página
Los scripts CGI tienen acceso a algo así como 20 variables de entorno, como QUERY_STRING y CONTENT_LENGTH mencionadas en la página principal. Aquí está la lista completa en NCSA.
Otras cuantas que pueden servirte:
fijará a PATH_INFO a "/path/info/here". Comúnmente usado para datos tipo ruta, pero puedes usarlo para cualquier propósito.http://www.myhost.com/mypath/myscript.cgi/path/info/here
Así que el URL del script que está siendo ejecutado es, en Perl,
"http://$ENV{'SERVER_NAME'}:$ENV{'SERVER_PORT'}$ENV{'SCRIPT_NAME'}"
El URL completo del script con el que fue invocado tambien puede tener PATH_INFO y QUERY_STRING al final.
Una vez más, vélas todas en la lista completa de NCSA's.
De regreso al principio de la página
La mayoría de los scripts CGI regresan datos HTML, pero puedes regresar cualquier tipo de datos que tú quieras. Solamente usa el tipo MIME correcto en la línea "Content-type:", seguida por la línea en blanco requerida, seguida por los datos de los recursos que estás enviando de regreso. En el caso de los archivos HTML, esos datos es el texto HTML. En el caso de imágenes, audio o video son datos binarios. Por ejemplo, para responder con un archivo gif, usa:
Content-type: image/gif
GIF89a&%*$@#--- contenido binario del archivo GIF aquí ---$(*&%(*@#......
Tu archivo HTML puede cargar una imágen generada por script con
<img src="gifmaker.cgi?param1=value1¶m2=value2">
Uno de mis ejemplos favoritos es was el Render Interactivo de Gráficas, que renderea íconos 3-D de acuerdo con los colores, forma, textura, iluminación, etc. que definas. Puedes usar el ícono de resultado en tus páginas Web como balas de lista o reglas horizontales mejoradas.. Nota: Este sitio ha perdido temporalmente su lugar; el autor dice que éste será eventualmente el punto de la nueva localización.
Los tipos MIME son cadenas de caracteres estándar de caso sensitivo que identifican el tipo de datos usado a través de Internet para muchos propósitos. Comienzan con el tipo general de datos (como text, image, o audio), seguido por un slash, y terminando con el tipo específico de datos (como html, gif, or jpeg). Los archivos HTML se identifican con text/html, y los GIFs y JPEGs se identifican con image/gif y image/jpeg.
De regreso al principio de la página
GET y POST son dos métodos diferentes definidos en HTTP que hacen cosas bastante diferentes, pero ambos son capaces de enviar remisiones de formas al servidor.
Normalmente, GET es usado para obtener un archivo u otro recurso, posiblemente con parámetros especificando más exactamente lo que se necesita. En el caso de una entrada por forma, GET incluye completamente en el URL, como
http://mihost.com/mipath/miscript.cgi?nombre1=valor1&nombre2=valor2
GET es como tu navegador baja la mayoría de los archivos, como archivos HTML e imágenes. Puede ser usado también en la mayoría de los envíos si no hay muchos datos (el límite varía de navegador a navegador).
El método GET es idempotente, lo cual significa que el efecto lateral de muchas peticiones GET idénticas es el mismo que para una sola petición GET. En particular, los navegadores y proxies pueden obtener respuestas GET del caché, así que dos remisiones de formas idénticas podrían no llegar a tu script CGI. Así que no uses GET si quieres registrar cada petición, de otra manera almacena los datos de cada petición.
Normalmente POST es usado para enviar un pedazo de datos al servidor para ser procesado, cualquier cosa que esto signifique. (El nombre POST puede venir de la idea de postear una nota en un grupo de discusión o de noticias.) Cuando una forma HTML se remite usando POST, tus datos de la forma se amarran al final de la petición POST en su propio objeto. Esto no es tan rápido ni tan fácil como al usar GET, pero es mucho más versátil. Por ejemplo, puedes enviar un archivo completo usando POST. Tambien, el tamaño de los datos no está limitado como en GET.
Esto es tras bambalinas, de cualquier manera. Para el programador CGI, GET y POST trabajan casi idénticamente, y son igual de usar. Algunas ventajas de POST son que no estás limitado sobre los datos que quieres remitir, y puedes contar con que tu script sea llamado cada vez que la forma sea remitida. Una ventaja de GET es que tu remisión completa de la forma puede ser encapsulada en un URL, como una hiperliga o un marcador (aunque ve cómo AutoPOST hace esto con POST).
De regreso al principio de la página
Normalmente, cuando tu script CGI imprime los encabezados "Content-type:", "Location:", u otros, el servidor analiza estos encabezados y genera la respuesta HTTP apropiada para el usuario. Ocasionalmente puedes querer un control más fino sobre la respuesta HTTP. La mayoría de los servidores Web soportan scripts de encabezados no-analizados (o "NPH"), que generan una respuesta HTTP completa y omite el análisis normal del servidor.
Para usarlos, necesitas saber un poco de HTTP-- específicamente, los formatos de líneas de estado y líneas de encabezado.
En tu script de encabezado no-analizado, solamente imprime el HTTP completo de las líneas de estado y encabezado donde un script normal imprimiría la línea "Content-Type:". Incluye la línea en blanco de trailer. Cualquier cosa que imprima tu script se envía al usuario verbatim, como la respuesta HTTP completa, sin modificaciones del servidor.
Nombra tus scripts NPH comenzando con algo con "nph-", como "nph-miscript.cgi"; cada script cuyo nombre comienza con "nph-" será manejado como un script NPH. Esto funciona en la mayoría de los servidores, inlcuyendo Apache y NCSA. Otros servidores pueden usar esquemas diferentes para identificar scripts NPH; lee los documentos o pregunta a tu webmaster.
Como un ejemplo de un script NPH, ve CGIProxy.
Si esto es confuso, no te preocupes. En el extraño caso de que alguna vez necesites un script NPH, esto tendrá sentido.
De regreso al principio de la página
De Regreso a la Página Principal
| Ultimo Modificado: Abril 18, 1998 | http://www.jmarshall.com/easy/cgi/spanish/cgi_footnotes.html |