Sección 0 - ¿Por qué este FAQ no responde a mis preguntas?
Sección 1 - Que hace WWWOFFLE (y que no)
Q 1.1 ¿Soporta WWWOFFLE http, ftp, finger, https, gopher, ...?
Q 1.2 ¿WWWOFFLE funciona en otros sistemas aparte de UNIX?
Q 1.3 ¿Puedes cambiar WWWOFFLE para que las páginas que genera ...?
Sección 2 - Como usar WWWOFFLE para servir una intranet
Q 2.1 ¿Puede el proxy WWWOFFLE ser accedido por otros clientes aparte de localhost?
Q 2.2 ¿Por qué los clientes remotos no pueden acceder al proxy WWWOFFLE?
Q 2.3 ¿Por qué los clientes remotos siguen todos los enlaces?
Q 2.5 ¿Cómo puedo tener diferentes configuraciones para diferentes grupos de usuarios?
Sección 3 - Que mirar cuando WWWOFFLE falla
Q 3.1 ¿Por qué mi navegador devuelve una página vacía con WWWOFFLE?
Q 3.2 ¿Por qué WWWOFFLE no puede encontrar un huésped cuando el navegador si puede?
Q 3.3 ¿Por qué mi navegador dice "Conexión cortada por el huésped remoto" cuando navego?
Q 3.4 ¿Por qué siguiendo un enlace en un servidor FTP me lleva al servidor incorrecto?
Q 4.1 ¿Por qué mi navegador no empieza el applet XYZ?
Q 4.2 ¿Están soportados los nombres de applets en unicode?
Q 4.3 ¿Por qué mi navegador Netcape saca la excepción de seguridad "trustProxy"?
Sección 5 - Características No documentadas de WWWOFFLE
Q 5.1 ¿Cómo puedo ver las páginas monitorizadas que se vieron la última vez En Linea?
Q 5.2 ¿Cómo puedo hacer una recogida recursiva en un intervalo regular?
Q 5.3 ¿Cómo puedo hacer que los usuarios no puedan acceder al indice?
Q 5.4 ¿Cómo puedo usar Junkbuster con WWWOFFLE?
Sección 6 - Más información acerca de WWOFFLE
Q 6.1 ¿Quién escribió WWWOFFLE, Cuando y Por qué?
Q 6.2 ¿Que listas de distribución sobre WWWOFFLE hay disponibles?
Q 6.3 ¿Cómo reporto fallos en WWWOFFLE?
Algunos de los protocolos están soportados y otros no.
http : Sí
La versión original de WWWOFFLE solo soportaba http.
ftp : Sí
Desde la versión 2.0 ha habido soporte para URLs ftp.
finger : Sí
Desde la versión 2.1 ha habido soporte para finger. Aunque este no es un
protocolo estándar para hacer "proxy" no hay ninguna razón para que no se pueda realizar satisfactoriamente.
https : Sí
Desde la versión 2.4 ha habido soporte transparente para
conexiones "Secure Socket Layer" (SSL). Esto inclute el protocolo https.
gopher : No
Este es un protocolo que es menos popular ahora que la WWW ha despegado.
Mirando a los navegadores que lo soportan, no parece imposible, pero el mercado para ello es muy limitado.
Por ejemplo DOS / Win3 / Win95 / WinNT / OS/2.
UNIX = Sí
Este es el sistema para el cual fué diseñado en un principio
,debería funcionar en muchas versiones de UNIX.
Se que funciona en Linux, SunOS 4.1.x, Solaris 2.x, *BSD.
DOS/Win3 = No
El programa no fué diseñado para DOS, los nombres usados y la realización de
multi-proceso del programae no lo permiten.
Win95/Win98/WinNT = Sí
Hay disponible una versión Windows de 32-bit del programa gracias al kit de desarrollo
de Cygwin que provee una librería de llamadas UNIX en MS Windows.
OS/2 = Quizás
No sé de un equivalente para el producto de Cygwin para OS/2, si existe
entonces es posible portarlo como se hizo para Windows 95 /
Windows NT.
Esta es una pregunta que me preguntan a menudo. La gente quiere ver Javascript, imágenes, diferentes colores ... en las página web que WWWOFFLE genera. Desde la versión 2.2 esto no es un problema ya que es posible cambiar todas las páginas web que WWWOFFLE genera. Esto significa que el color de fondo y el tamaño de la fuente pueden ser cambiados para cubrir sus necesidades. Para saber como hacer esto mire en el directorio /var/spool/wwwoffle/html/messages y lea el fichero README.
Sí, puede, esa opción ha estado presente desde el principio. Los otros clientes pueden ser cualquier tipo de ordenador conectado al servidor que esté ejecutando el programa wwwoffled. El único requerimiento es que deben estar conectados en red con el servidor y que deben tener el navegador configurado para acceder al proxy WWWOFFLE.
La situación por defecto en el fichero wwwoffle.conf es la de no permitir ningún acceso a clientes
diferentes de localhost. Para permitirles el acceso al proxy el fichero
wwwoffle.conf necesita ser editado como se describe abajo y la nueva configuración debe ser cargada.
La sección AllowedConnect del fichero de configuración contiene una lista de huéspedes
que tienen permitida la conexión con el proxy WWWOFFLE. Estos nombres se comprueban
contra los nombres que WWWOFFLE coge cuando la conexión se realiza. De esta forma el acceso es
permitido o denegado. Las entradas de la lista pueden contener comodines pero no se realizan comprobaciones de nombres extra.
Por ejemplo si está utilizando el espacio de direcciones IP privadas 192.168.*.* para su intranet
entonces su sección AllowedConnect el el fichero de configuración debería ser algo como esto.
AllowedConnect
{
192.168.*
}
Esto permitirá la conexión al proxy WWWOFFLEa todos los huéspedes que vengan de este rango de direcciones IP.
Algunos de los enlaces que son generados en las páginas web que vienen del
proxy WWWOFFLE necesitan apuntar a otras páginas del proxy. Para ser capaza de hacer esto
el nombre del huésped ejecutando el proxy necesita ser especificado en la sección LocalHost
del fichero de configuración.
Por ejemplo si el ordenador ejecutando el proxy WWWOFFLE se llama www-proxy entonces
la sección LocalHost del fichero de configuración sería algo como.
LocalHost
{
www-proxy
localhost
127.0.0.1
}
El primer de los nombres es el que ussará WWWOFFLE para generar los enlaces.
Los otros son usados por servidores que no son guardados por el proxy.
La seguridad es una aspecto que he estado considerando cuando he escrito WWWOFFLE aunque no ha sido una de mis mayores preocupaciones. Los aspectos son los listados abajo. Para la versión Win32 se debe anotar que en Win95/98 no hay la seguridad a nivel de usuario que provee UNIX. No es posible crear ficheros que solo puedan ser leidos por WWWOFFLE y no por los otros usuarios. Los aspectos de seguridad que están presentes en WWWOFFLE no son, pues, aplicables a estos sistemas. Contraseña del fichero de configuración Este fichero puede tener una contraseña especificada en su sección StartUp que se usa para limitar el acceso a las opciones de control WWWOFFLE. Si se activa la contraseña, esta debe ser usada para poner a WWWOFFLE En Linea, Fuera de Linea, Purgar la caché, Parar el servidor, editar el fichero de configuración etc.. Si tiene puesta una contraseña entonces debe hacer que el fichero solo pueda ser leido por los usuarios autorizados. La contraseña se manda como texto plano cuando se usa el programa wwwoffle para controlar el servidor wwwoffled. La encriptación usada para la autentificación de la página web no es segura. Autentificación del Proxy Con la habilidad de controlar el acceso a WWWOFFLE usando el Método de Autentificación de Proxy de HTTP/1.1 nos encontramos con sus riegos de seguridad añadidos. Son basicamente los mismos que para la contraseña del fichero de configuración, los nombres de usuarios y las contraseñas están en texto plano y la contraseña del fichero de configuración que se manda al servidor usa el mismo sistema de encriptación inseguro. uid/gid del servidor WWWOFFLE El uid y el gid del proceso del servidor wwwoffled puede ser controlado por las opciones run-uid y run-gid en la sección StartUp del fichero de configuración. Estos uid/gid necesitan poder leer el fichero de configuración (la escritura no es requerida a menos que se use la página de edición interactiva) y tener acceso de lectura/escritura al directorio almacén. Si se usa esta opción entonces el servidor debe ser comenzado por root. Borrar URLs pedidas Solo el usuario que realiza una petición de página puede borrar la petición, y es entonces cuando el borrado se realiza de forma inmediata. Esto es así porque la contraseña se realiza indexando el contenido del fichero en el directorio se salidas. Esto significa que el acceso de lectura a este directorio debe ser negado para que sea seguro. El servidor web incorporado Es un servidor muy simple que seguirá enlaces, como una característica de seguridad, solo si los ficheros pueden ser leidos por todo el mundo. También deben estar en un directorio que el servidor wwwoffled pueda leer. No se realiza la comprobación para cada directorio por lo que ficheros con acceso de lectura para todo el mundo en un directorio que solo puede ser leído por el uid que ejecuta wwwoffled no es seguro. Accediendo a la caché No hay ningún problema general dejando que los usuarios puedan acceder a la caché si este es de solo lectura (pero vea URLs con contraseña debajo). Lo único de lo que se tiene que preocupar es que la purga se realiza usando la hora de acceso de los ficheros, entonces ejecutar grep en la caché estropeará la purga. URLs con contraseña Las URLs que usan usuario y contraseña deben ser almacenadas en la caché. Para simplificar no están ocultas de ninguna manera. Esto significa que cualquier URL que use usuario/contraseña puede mostrarse en el fichero de log (con los niveles Debug o ExtraDebug). Los ficheros en la caché también contienen la información usuario/contraseña por lo que no deben ser accesibles a los usuarios por esta razón.
Cuando hay dos grupos de usuarios que deben acceder a la misma caché de WWWOFFLE
pero cada grupo debe tener diferentes configuraciones de WWWOFFLE, es posible correr
dos instancias de WWWOFFLE.
Por ejemplo, en una escuela puede requerirse que los estudiantes puedan acceder a la caché,
pero no puedan pedir nuevas páginas. Las profesores deben ser capaces de acceder a la misma caché
y ser capaces de usar WWWOFFLE En Línea y pedir las páginas mientras están Fuera de Línea.
Las dos configuraciones de WWWOFFLE serán básicamente iguales, pero habrá unas
cuantas diferencias como se detalla abajo.
-- wwwoffle.student.conf -- -- wwwoffle.teacher.conf --
StartUp | StartUp
{ | {
http-port = 8080 | http-port = 9080
wwwoffle-port = 8081 | wwwoffle-port = 9081
password = secret | password = teacher
} | }
|
DontRequestOffline | DontRequestOffline
{ | {
*://*/* |
} | }
|
AllowedConnectUsers | AllowedConnectUsers
{ | {
| teacher1:password1
| teacher2:password2
} | }
|
AllowedConnectHosts | AllowedConnectHosts
{ | {
| teacher1pc
| teacher2pc
} | }
Las dos copias de WWWOFFLE deberán usar distintos puertos. Usan el mismo directorio de
caché y por lo tanto las mismas páginas webs estarán disponibles para ambos grupos de usuarios.
Necesitará una contraseña en el fichero de configuración de los alumnos para evitar
que cambien el fichero, pero en el de los profesores puede no ser requerida.
Para evitar que los alumnos puedan usar la versión de los profesores debe usar las secciones
AllowedConnectHosts o AllowedConnectUsers en el fichero de configuración.
De esta forma se restringirá el acceso a las máquinas a las que tengan acceso los profesores
o requerirán la introducción de usuario/contraseña antes de comenzar la navegación.
En el ejeplo anterior los alumnos no tienen permitida la petición de páginas mientras están
Fuera de Línea. Esta versión de WWWOFFLE no se usará nunca en modo En Línea por lo que no hay
ninguna forma de que los alumnos puedan navegar En Línea. Sólo la versión de los profesores
podrá ser usada En Línea.
Cuando se está usando un navegador para visitar una página web no se devuelve nada cuando se usa WWWOFFLE como proxy pero cuando el sitio es accedido directamente sin WWWOFFLE la página es visible. Esto puede deberse a un número de causas (todas se me han reportado o testeadas por mi mismo): a) El servidor al que esta accediendo requiere la cabecera User-Agent. Si no está presente o está puesta a un valor no común (no Netscape o IE) entonces devuelve una página vacía. En este caso si tiene puesto en el fichero de configuración que la cabecera CensorHeader quite la cabecera User-Agent entonces debe o no censurar esta cabecera o reemplazarla por una cadena que sea aceptable. b) Como lo descrito arriba, pero no importa el valor de la cadena para devolver una página no vacía. La solución es la misma excepto que se puede usar cualquier cadena en la cabecera User-Agent. c) El servidor web usa "cookies" para mantener el estado. Esta es una práctica común en sitios que están más preocupados de la forma que del contenido, normalmente sin notificación. d) El navegador y el servidor tratan de usar las extensiones del protocolo HTTP/1.1 que WWWOFFLE ignora.
Hay dos posibles razones para ello. 1) Un servidor Sin autoridad. 2) Un cambio en la configuración del servidor DNS desde que se comenzó wwwoffle. Cuando WWWOFFLE mira un nombre de huésped usa la llamada de función de la librería standar UNIX (libc) gethostbyname(). Esta solo devolverá la información del huésped si el nombre que recibe desde el servidor de nombres (DNS) tiene autoridad. No se devuelve una respuesta sin autoridad, pero se activa el estado de error. Los proyectos de grandes navegadores (Netscape en particular) usa una respuesta sin autoridad si está disponible. Esto significa que puede acceder a sistios que no están disponibles a WWWOFFLE. El código fuente para hacer esto no es obvio y requiere algunas funciones de bajo nivel en la librería de resolución de nombres (libresolv). Este problema solo pasa cuando el servidor de nombre que está usando tiene una conectividad pobre a otros servidores de nombres o a algun que otro problema de resolución de nombres. Si es posible, la solución pasa por utilizar otro servidor de nombres, o quejarse al administrador del que está usando. [Si alguien tiene código fuente para resolver nombres sin autoridad por favor diganmelo.] Otra razón posible es que el servidor de nombres que se configuró cuando WWWOFFLE comenzó la ejecución no sea válido. Esto puede pasar por ejemplo si el fichero /etc/resolv.conf fue cambiado despues de que wwwoffled se ejecutara. Esto no es un problema solo de WWWOFFLE, pues afectará a la mayoría de programas que usen resolución de nombres. La razón es que la parte de resolución de nombresde la librería standard de UNIX (libc) es inicializada cuando el programa se comienza a ejecutar. Cuando la resolución de nombres se realiza más tarde seguirá usando la misma configuración que era correcta cuando el programa comenzó su ejecución. Esto puede pasar sin que usted se de cuenta porque algunos de los programas de configuración PPP "amigables" cambiarán el fichero /etc/resolv.conf dependiendo del ISP al que se conecte.
Esto pasa cunado se usa Netscape para acceder a algunas páginas web. La causa no se conoce, pero el problema solo se ve cuando se usa WWWOFFLE y no cuando se hace una conexión directa. [Creo que el problema (una peculiaridad de Netscape) se ha solucionado en la versión 2.2c de WWWOFFLE, por favor diganme si no se ha arreglado.]
Si hay un directorio llamado '/dir' en un servidor ftp server y carga la página 'ftp://server/' se obtiene una lista de directorios que incluye un enlace a '/dir'. Si sigue este enlace le llevará a 'ftp://server/dir/', pero en algunos navegadores va a 'ftp://dir/' en vez de al anterior. Creo que este comportamiento es debido al navegador y no a WWWOFFLE. Si usted fue a 'http://server/' y siguió el enlace a '/dir/' usted esperaria ir a 'http://server/dir/' y no a 'http://dir/'. Esto es de sentido común. Porque el navegador hace diferencias entre ftp y http no estoy seguro. [Esto debe estar arreglado en la versión 2.1 de WWWOFFLE, por lo que no es aplicable a esta versión del FAQ]
[Walter Pfannenmueller <pfn@online.de> escribe:] Supongo que ha puesto en marcha el soporte de java. Su navegador dice algo así como "No puedo empezar el Applet XYZ.class". Mire a ver si el fichero ha sido correctamente bajado por WWWOFFLE. Si el fichero es accesible, abra una consola java (su navegador debe tener algo parecido) y lea más detalles sobre el problema. Problablemente es una violación de seguridad. Todos los navegadores tienes su propio clase Administradora de Seguridad y debe consultar el manual para ver como puede rebajar estas restricciones. Si su applet intenta entrar en contacto con alguna función del servidor (servlets, RMI, CORBA), hemos llegado al final de las posibilidades de un lecto Fuera de Línea.
[Walter Pfannenmueller <pfn@online.de> escribe:] No lo sé. Yo transformo estos nombres a codificación UTF8 y el resto depende de los que haga con él su sistema de fiecheros o el sistema de ficheros del huésped. Los compiladores de Java también tienen problemas con unicode, aunque sebería estar soportado. Apreciaría cualquier información que ayude a esclarecer la oscuridad. Me gustaría saber como programar tranformaciones de Unicode a UTF8. La implementación en javaclass.c parece un poco enrevesada.
[Walter Pfannenmueller <pfn@online.de> escribe:]
El mensaje de error debería ser
No es posible resolver la IP para el huésped ... Vea la propiedad trustProxy.
El navegador Netscape intenta verificar la IP del húesped del código fuente del applet.
Minetras de está Fuera de Línea esto no es posible. Por lo tanto debe persuadir al navegador de que confie en el proxy.
Para hacer esto debe encontrar el fichero de preferencias preferences.js en UNIX o prefs.js en Windows. Edite el fichero,
aunque diga "No editar" u agrege la siguiente línea
user_pref("security.lower_java_network_security_by_trusting_proxies", true);
Asegurese de haber cerrado todas las ventanas del navegador, porque el fichero de preferencia
será sobreescrito al salir. Esto debería bastar para todos los Netscape 4.0x y 4.5.
Para más información eche un vistazo en
http://developer.netscape.com/docs/technote/security/sectn3.html
La forma más fácil de hacer esto es yendo al índice de páginas monitorizadas y ordenar las páginas por "Hora de Acceso" (http://localhost:8080/index/monitor/?atime). Cada página será accedida cuando sea monitorizada por lo que las más recientes serán las que esten al principio de la lista.
Esto es una combinación de la opción de recogida recursiva y la opción de monitor. Si selecciona la página que quiera en el índice de recogida recursiva (http://localhost:8080/refresh-options/) con las opciones que quiera y pulsa el botón, se le presentará una página diciéndole que su petición se ha grabado. Hay un enlace hallí que le permitirá monitorizar esta petición, que le llevará a la página normal del monitor (http://localhost:8080/monitor-options) pero con la URL ya llena.
El control a los índices puede ser denegado a los usuarios usando la sección del fiechero de configuración DontGet.
DontGet
{
http://localhost:8080/index
}
Debe asegurarse de que el nombre del huésped que le de es el primero en la sección
LocalHost porque este es el nombre que se chequeará.
El Cazador de Basura de Internet(Junkbuster) es un programa que puede filtrar los anunios y otras carácterísticas de las páginas web. Las versiones más recientes de WWWOFFLE añaden muchas de las características de JunkBuster, pero no todas ellas. Si mira a las opciones que WWWOFFLE tiene, puede decidir que no necesita Junkbuster. Si decide que quiere usar los dos programas tiene dos opciones: 1) Navegador <-> WWWOFFLE <-> JunkBuster <-> Internet Todas las páginas que los usuarios pidan y que JunkBuster bloquee tendrán los mensajes de error almacenados en la caché de WWWOFFLE. Cualquier recogida simple o recursiva de imágenes que realice WWWOFFLE en segundo plano pasan a travé de JunkBuster y los mensaje de error de JunkBuster serán almacenados. 2) Browser <-> JunkBuster <-> WWWOFFLE <-> Internet Cualquier páginas que el usuario pida y que Junkbuster bloquee no se almacenarán en la caché de WWWOFFLE. Cualquier búsqueda simple o recursiva de imágenes que realice WWWOFFLE en segundo plano no pasará a través de JunkBuster y no se almacenará en la caché de WWWOFFLE pero será bloqueada cuando el navegador trate de verlas. Si decide que WWWOFFLE hará muchas recogidas pero está usando el navegador Fuera de Línea entonces el primer método es el mejor. Si decide que solo usará el navegador En Línea y que no pedirá páginas Fuera de Línea entonces el segundo método es mejor. Si la más importante característica de JunkBuster es la de reducir ancho de banda entonces el primer método es el mejor, ya que parará a WWWOFFLE las páginas basura.
Section 6 - Más información acerca de WWWOFFLE
Q 6.1 ¿Quién escribió WWWOFFLE, Cuando y Por qué?
El programa WWWOFFLE fue escrito por Andrew M. Bishop (amb@gedanken.demon.co.uk) en 1996,97,98. Hay una página web de WWWOFFLE accesible desde la página web del autor en http://www.gedanken.demon.co.uk/ . Es actualizada con noticias acerca del programa, cada vez que sale una nueva versión. Una versión anterior del programa escrito por el mismo autor en perl ha sido usada por un tiempo pero se dió cuenta de que la funcionalidad de la versión era insuficiente excepto para un uso reducido. El trabajo en el prorama WWWOFFLE en si mismo enpezó eb las vacaciones de Navidad de 1996, inicialmente era un apaño para mejorar la versión en perl. Después de la liberación de la versión Beta 0.9 a comienzo de Enero de 1997 se generó mucho interés, lo que condujo a la liberación de la version 1.0 más tarde ese mismo mes. Hasta Diciembre de aquel año le siguieron más versiones hasta que la versión 2.0 fue liberada. Esta contenía nuevas características (como FTP) y incluía una reescritura de gran parte del código para hacerlo más fácil de mantener y mejorar, Esto incluyó cambiar completamente el formato de la caché. La versión 2.1 fue liberada en Marzo de 1998 con algunas nuevas características, la versión 2.2 en Junio de 1998 con más características y la versión 2.3 en Agosto de 1998 con todavía más características. La versión Win32 del programa fue posible gracias a la versión beta-20 del Kit de desarrollo de Cygwin a finales de Octubre de 1998 cuando la versión 2.3e de WWWOFFLE fue liberada. El programa WWWOFFLE pruede ser distribuido libremente de acuerdo a los términos de la Licencia Pública General GNU (GPL) (vea el fichero `COPYING').Q 6.2 ¿Qué listas de correo sobre WWWOFFLE hay disponibles?
Ahora hay cuatro listas de correo disponibles para WWWOFFLE. Se puede suscribir de dos formas diferentes - en la página web de usuarios de WWWOFFLE y via correo electrónico. wwwoffle-announce Para anuncios de nuevas versiones de WWWOFFLE. wwwoffle-beta-announce Para pre-anuncios de nuevas versiones de WWWOFFLE para beta-testers. (Suscribase solo si está deseando dar su tiempo para testear WWWOFFLE). wwwoffle-users Para discutir de características de WWWOFFLE, excluyendo características específicas del sistema operativo. wwwoffle-win32 Para discutir sobre WWWOFFLE en sistemas Win32. La dos primeraas son solo para anuncios del autor de WWWOFFLE, no está permitido discutir en ellas. Las dos siguientes están abiertas para publicar a los miembros de la lista y a otros que no están suscritos. Para suscribirse por correo electrónico mande un mensaje a majordomo@gedanken.demon.co.uk con el mensaje 'subscribe <group-name>' en el cuerpo, p.e. 'subscribe wwwoffle-announce'.Q 6.3 ¿Cómo reporto fallos en WWWOFFLE?
Por correo electrónico, mandemelos a amb@gedanken.demon.co.uk y ponga WWWOFFLE en algún sitio de la línea de tema. Puede tambien reportar fallos o hacer comentariosor desde el formulario en la pagina web de WWWOFFLE situada en http://www.gedanken.demon.co.uk/ . Antes de hacer esto, debería chequear la FAQ y la página web de WWWOFFLE para ver si la respuesta esta allí. Si no está y quiere reportarmelo no olvide que ayuda si usted puede reproducir el error, en particular si empezó wwwoffled como 'wwwoffled -d5 -c wwwoffle.conf' y captura la salida de depurado para la sesión que muestra el error.