Memoria Trabajo Final de Carrera Filtrado Web

FILTRADO WEB CON JAVA
José Antonio Placín Holguín

ETIS
Consultor:
David Carrera Pérez
Enero 2008
Filtrado WEB con JAVA J.A.Placín
AGRADECIMIENTOS
A Loli, Miguel, Ana y Triky.

A Loli, porque sin tu apoyo y esfuerzo nunca hubiera llegado hasta aquí.
“Un poquito más y ya estará puesto el suelo del porche”.
A Miguel y Ana, porque siempre perdonáis mis ausencias.
A Triky, siempre has estado a mi lado.
2
RESUMEN Y PLANIFICACIÓN
FILTRADO DE PÁGINAS WEB CON JAVA.
OBJETIVOS GENERALES Y ESPECÍFICOS:

En la empresa, los centros de enseñanza, el hogar, etc... es importante que los equipos conectados a
internet sean usados para aquello, para lo que han sido destinados.
Internet es un herramienta imprescindible, pero fácilmente se desvirtúa su utilidad cuando los usuarios
hacen uso de ella inadecuadamente.
Por ello una herramienta de filtrado como la que desarrollaremos en este TFC es necesaria para que el
administrador del sistema controle esos usos. La aplicación generada, tendrá como objetivo principal
dotarle, de una herramienta de fácil configuración, para el control del tráfico entre el equipo e internet.
Esta aplicación con una filosofía cliente-servidor, que correrá de manera transparente para el usuario,
recibirá las peticiones de conexión desde el navegador y las analizará, permitiendo al administrador realizar
las siguientes acciones:
−Prohibir el acceso a una lista de dominios configurable.
−Bloquear páginas según su contenido, mediante una lista de palabras prohibidas que también será
configurable por niveles (dependiendo de la repetición de las mismas).
−Restringir el acceso a través de los puertos de una lista configurable.
−Y sobre todo registrar:
−Páginas visitadas y tiempo de conexión
−Páginas bloqueadas y hora de intento conexión
−Puerto bloqueado y hora de intento conexión.
−Comunicación realizada (Registrar todo el tráfico de algún puerto en concreto, a seleccionar)
La programación se realizará en Java, con lo que será portable a cualquier sistema, cuyo único requisito
será tener instalada una máquina virtual Java (JVM).
Organización:
En primer lugar se expone el plan de trabajo diseñado para la consecución de los objetivos. A continuación
se explicará la situación actual del filtrado web, y se introducirá algo de teoría sobre las tecnologías en las
que se basa la aplicación.
Seguidamente se muestra el desarrollo llevado a cabo durante el diseño, para continuar en los últimos
apartados explicando su implementación.
Al final se explican la instalación y manejo de la aplicación resultante
3
PLANIFICACIÓN CON PLAZOS Y TEMPORIZACIÓN:
Primer plazo: 2 semanas (del 3 al 16 de Octubre)

Descripción: Recogida de documentación y requisitos:
−Aplicaciones ya existentes que realicen labores semejantes.
−Información sobre protocolos implicados.
−Definición de la interface de usuario de la aplicación.
−Descripción de casos de uso.
Al final obtendremos:
•El día 14 de Octubre entregar el 1º informe de progreso quincenal.
•Descripción de algunas aplicaciones existentes y principales diferencias con nuestro
proyecto.
•Guiones de casos de uso.
•Primeras inserciones en la memoria del proyecto.
•Ir adjuntando fuentes de información a la bibliografía.
Segundo plazo: 4 semanas (del 17 de Octubre al 14 de Noviembre)

Descripción: Análisis y especificación:
−Revisión de los casos de uso y especificación formal de los mismos.
−Identificación de las clases y sus relaciones.
−Definición de la interface de usuario de la aplicación.
−Estudio de la API de Java.
•El dia 28 de Octubre entregar el 2º informe de progreso quincenal.
•El día 4 de Noviembre entrega de la 2ª PAC.
•Modelo del análisis.
•Continuación de la elaboración de la memoria del proyecto.
•Continuar adjuntando fuentes de información a la bibliografía.
Tercer plazo: 5 semanas (del 15 de Noviembre al 18 de Diciembre)

Descripción: Diseño e implementación:
−Diseño de los casos de uso.
−Diseño de la persistencia ( ficheros de configuración y datos).
−Diseño de la interface de usuario.
−Implementación de todo ello.
−Primeras pruebas de la aplicación.
•El dia 25 de Noviembre y el 9 de Diciembre entregar el 3º y el 4º informes de progreso
quincenal.
•El día 16 de Diciembre entrega de la 3ª PAC.
•Primer prototipo de la aplicación.
•Continuación de la elaboración de la memoria del proyecto.
•Continuar adjuntando fuentes de información a la bibliografía.
4
Cuarto plazo: 5 semanas (del 18 de Diciembre al 21 de Enero)

Descripción: Depuración y entrega:
−Implementación de la aplicación.
−Depuración de la aplicación.
−Creación de la presentación del TFC.
•El dia 6 de Enero entregar el 5º informe de progreso quincenal.
•El día 16 de Diciembre entrega de la 3ª PAC.
•Aplicación.
•Memoria del TFC.
•Bibliografía.
•Manual de la aplicación.
•Presentación del TFC.
•El día 16 de Enero entrega de la memoria y aplicación.
•El día 21 de Enero presentación de la aplicación.
5
ÍNDICE DE CONTENIDOS
PORTADA Filtrado WEB con JAVA....................................................................................................... ...........1
AGRADECIMIENTOS....................................................................................................................... ...........2
RESUMEN Y PLANIFICACIÓN................................................................................................. ..................3
FILTRADO DE PÁGINAS WEB CON JAVA........................................................................... .................3
OBJETIVOS GENERALES Y ESPECÍFICOS:......................................................... .........................3
ORGANIZACIÓN:.............................................................................................................. ................3
PLANIFICACIÓN CON PLAZOS Y TEMPORIZACIÓN:................................................ ....................4
ÍNDICE DE CONTENIDOS................................................................................................................... .......6
ÍNDICE DE ILUSTRACIONES.................................................................................................... .................9
1 TEORÍA...................................................................................................................................................... ..10
1.1 ESTUDIO DE LA SITUACIÓN ACTUAL. ...................................................................... .......................10
1.1.2 EVALUACIÓN DE LA UTILIDAD.......................................................................................... .........12
1.1.3 EVALUACIÓN DEL USO........................................................................................................... ....12
1.2 PROTOCOLOS.......................................................................................................... ..........................13
1.2.1 PROTOCOLO HTTP. ................................................................................... ........................13
1.2.1.1 Introducción........................................................................................................................ ...13
1.2.1.2 Características.......................................................................................................... ............13
1.2.1.3 Peticiones (Request) HTTP ....................................................................... ..........................14
1.2.1.4 Respuestas (Response) HTTP......................................................................... ...................14
1.2.1.5 Cabeceras HTTP................................................................................................. .................15
1.3 LENGUAJE HTML........................................................................................................................... .....16
1.3.1 ESTRUCTURA DE LOS DOCUMENTOS HTML.............................................................. ...........16
1.3.2FORMULARIOS HTML............................................................................................ .....................17
2 ANÁLISIS............................................................................................................................................. ........18
2.1 REQUISITOS................................................................................................................ .......................18
2.2 DOMINIO.......................................................................................................................... ...................19
2.3 NEGOCIO............................................................................................................................... .............19
2.4 GLOSARIO DEL MODELO DE NEGOCIO......................................................................... .................20
Usuario:..................................................................................................................... .................20
Administrador:............................................................................................................................ .20
Servidor:.................................................................................................................... .................20
Petición:............................................................................................................................ ..........20
Permiso usuario:................................................................................................................... ......20
Puerto:.............................................................................................................................. ..........20
Dominio:.............................................................................................................. .......................20
Códigos ICRA: .................................................................................................................. .........20
Lista Dominios:............................................................................................................ ...............20
Lista Palabras:............................................................................................................. ...............21
Registro:.............................................................................................................. .......................21
2.5 DOCUMENTACIÓN TEXTUAL DE LOS CASOS DE USO.................................................................21
6
2.6 ESPECIFICACIÓN DE LAS CLASES......................................................................................... .........25
2.6.1 IDENTIFICACIÓN DE LAS CLASES DE IDENTIDAD.................................................................25
2.7 DIAGRAMAS DE COLABORACIÓN........................................................................................... .........27
Administrar registro: ............................................................................................................... ....27
Administrar códigos ICRA: ...................................................................................................... ...28
Administrar lista de palabras: ......................................................................... ...........................28
Comprobar petición: ........................................................................................... .......................28
Comprobar permisos usuario: .......................................................................... .........................29
Comprobar dominio: .................................................................................................. ................29
Comprobar puerto: ........................................................................................... .........................29
Solicitar recurso: .............................................................................................................. ..........29
Comprobar recurso: .............................................................................................................. .....30
Comprobar ICRA: ....................................................................................................... ...............30
Comprobar contenido: ............................................................................................. ..................30
Retransmitir recurso: ........................................................................................ .........................30
Comunicar resultado: ................................................................................................................ .30
Registrar petición: ............................................................................................................... .......30
2.8 INTERFACE DE USUARIO....................................................................................................... ..........31
Menú inicial:......................................................................................................................... .......31
Administrar usuarios:.................................................................................................. ................31
Administrar lista negra:.................................................................................................. .............32
Administrar dominios:............................................................................................... ..................32
Administrar códigos ICRA:....................................................................................................... ...33
Administrar registro:.................................................................................................................. ..33
Administrar puertos......................................................................................... ...........................34
3 DISEÑO......................................................................................................................................... .............35
3.1 DISEÑO DE LOS CASOS DE USO............................................................................... ......................35
Administrar usuarios:...................................................................................................... ............35
Administrar lista negra................................................................................................... .............36
Administrar dominios................................................................................................ ..................36
Administrar códigos ICRA...................................................................................................... .....37
Administrar puertos......................................................................................... ...........................38
Administrar registro................................................................................................................... ..38
3.2 DIAGRAMA ESTÁTICO DEL DISEÑO........................................................................ ........................39
4 IMPLEMENTACIÓN CON JAVA........................................................................................................... .......40
4.1 SOCKETS............................................................................................................................. ...............40
4.2 THREADS.......................................................................................................................................... ..40
4.3 PERSISTENCIA. ...................................................................................................................... .........41
4.4 API JAVA................................................................................................................................... ..........41
4.5 CLASES .................................................................................................................. ...........................44
Servidor: ....................................................................................................................... ..................44
ThreadServidor: .................................................................................................................... ..........44
7
Menu: ............................................................................................................................................. .46
CrearFicheros: ................................................................................................................... .............46
Usuario: ................................................................................................................. .........................47
Dominio: ................................................................................................................ .........................48
Peticion: .............................................................................................................................. ............48
CodigoICRA: ............................................................................................................................... ....49
Lista: .................................................................................................................................. .............49
ListaUsuarios: ....................................................................................................................... ..........50
listaCodigos: .................................................................................................................... ...............50
listaDominios: ............................................................................................................ .....................50
4.6 DIAGRAMA DE CLASES ......................................................................................................... ...........51
4.7 DIAGRAMA DE FLUJO SIMPLIFICADO DE LA APLICACIÓN .................................................... ......52
5 MANUAL DE LA APLICACIÓN.................................................................................................. ..................53
5.1 INSTALACIÓN................................................................................................................................. .....53
5.2 GESTIÓN ........................................................................................................................................ ....54
6 CONCLUSIONES................................................................................................................... .....................55
6.1 MEJORAS..................................................................................................................................... ......55
7 BIBLIOGRAFÍA................................................................................................................................... .........56
8 GLOSARIO........................................................................................................................... .......................57
8
ÍNDICE DE ILUSTRACIONES
Tabla peticiones HTTP...................................................................................................................... ..............14
Códigos respuestas HTTP............................................................................................................... ...............15
Modelo del dominio.............................................................................................................................. ...........19
Casos de usos del modelo de negocio.................................................................................... .......................19
Diagrama de clases de entidad............................................................................................ ..........................26
Colaboración caso de uso Administrar usuarios................................................................................. ............27
Colaboración caso de uso Administrar registro............................................................................................ ...27
Colaboración caso de uso Administrar dominios............................................................................ ................28
Colaboración caso de uso Comprobar petición......................................................................... .....................29
Colaboración caso de uso Comprobar recurso........................................................................................... ....30
Pantalla Menu Inicial.......................................................................................................................... .............31
Pantalla Administrar Usuarios.............................................................................................................. ...........31
Pantalla Administrar Lista Palabras......................................................................................... .......................32
Pantalla Administrar dominios........................................................................................................................ .32
Pantalla Administrar Códigos................................................................................................................... .......33
Pantalla Administrar Registro....................................................................................................................... ...33
Pantalla Administrar Puertos............................................................................................... ...........................34
Diagrama estático del diseño....................................................................................................................... ...39
Clase Servidor............................................................................................................................... .................44
Clase ThreadServidor............................................................................................................................ .........45
Clase Menu................................................................................................................................................... ..46
Clase CrearFicheros.................................................................................................................... ...................47
Clase Usuario........................................................................................................................ .........................47
Clase Dominio...................................................................................................................... ..........................48
Clase Peticion.................................................................................................................................... .............48
Clase CodigoICRA..................................................................................................................................... .....49
Clase Lista......................................................................................................................................... .............49
Clase listaUsuarios......................................................................................................................... ................50
Clase listaCodigos.......................................................................................................................... ................50
Clase listaDominios.................................................................................................................. ......................50
Diagrama de clases................................................................................................................ ........................51
Diagrama de flujo....................................................................................................................................... .....52
9
1 TEORÍA
1.1 ESTUDIO DE LA SITUACIÓN ACTUAL.

En una primera aproximación al estado actual del software especializado en el filtrado web, se observa
como el número de estas aplicaciones que hay en el mercado es enorme. Existen cientos de ellas.
Para un primer filtrado se han utilizado sitios de internet que promueven enlaces a software, y se han
seleccionado los más descargados por los usuarios, así como los mejor valorados. De todos ellos a
continuación hay una lista con algunos de los mejor colocados y sus características (no están ordenados por
ningún criterio).
FreeShield (FreeWare) Windows XP/2000/NT/ME/98
Características:
•Filtro de contenidos.
•Permite configurar el nivel de acceso según las necesidades del usuario.
•Protección contra virus.
•Protección contra programas publicitarios.
•Bloqueo de ventanas emergentes.
•Bloqueo de programas que realizan llamadas telefónicas (dialers).
•Elimina rastros de navegación en Internet.
•Totalmente configurable.
Naomi 3.2.90 (FreeWare) Windows XP/2000/NT
Características:
•Análisis heurístico que reconoce nuevos contenidos en forma automática.

•Análisis semántico del contenido de cada página web, de dominios y de enlaces.
•Reconoce el sistema de etiquetado ICRA.
•Fácil de usar: no es necesario configurarlo.
•Puede ser usado en conexiones lentas (no realiza transferencias ni actividad de fondo)
•Filtro por contenidos.

•Restringe el acceso a Internet.
•Interfaz sencilla.
Anti-Porn v9.1.3.29 (ShareWare) Windows 9x/2000/XP/Vista
Características:
•Filtrado por URL.

•Protege de contenidos inadecuados para el usuario.
•Restringe los chats.
10
•Guarda historiales.
•Interfaz sencilla.
Internet Watcher 2000 1.9c (ShareWare) Windows 95/98/ME/NT/2000
Características:
•Filtros de publicidad, información y páginas web.

•Registro de conexiones
•Navegación 150% mas rápida.
•Protección de la privacidad.
•Filtrado de ventanas emergentes.
•Ahorro de un 50% de ancho de banda en la red.
•Funciones de estadísticas detalladas.
Net Nanny Home Suite (ShareWare) Windows Vista/XP/2000
Características:
•Muy fácil de usar.

•Bloqueo de pornografía y otros contenidos.
•Control de la actividad de Internet desde cualquier sitio.
•Registro de la actividad de internet y mensajería instantánea.
•Configurable por usuarios.
•Actualización automática sin coste adicional.
Censor Net Professional (OpenSource) Debian 4.0
Características:
•Análisis léxico en tiempo real y múltiples idiomas.

•Análisis de imágenes.
•Millones de URL's censadas.
•Reglas basadas en usuarios o grupos.
•Registros de visitas y conexiones.
Como se puede ver todos implementan las funcionalidades que se han previsto para el presente desarrollo
y bastantes más, pero no son multiplataforma.
Un tema que se ha considerado tan interesante como para decidir implementarlo en esta aplicación es el
reconocimiento del etiquetado ICRA, descubierto durante la investigación de las aplicaciones anteriores. El
estudio de sus especificaciones nos permitirá filtrar un gran número de sitios y contenidos con rapidez, pues
sólo se ha de analizar la etiqueta ICRA, en la que aparecen una serie de códigos, que avisan del tipo de
contenido.
11
Etiqueta ICRA de una página real, con los códigos marcados en color azul:
<META HTTPEQUIV="picslabel" content='(pics1.1 "http://www.icra.org/ratingsv02.html" l gen true
for "http://www.eportalsur.com.ar" r (cb 1 lz 1 nz 1 oz 1 vz 1)
"http://www.rsac.org/ratingsv01.html" l gen true for "http://www.eportalsur.com.ar" r (n 0 s 0 v 0
l 0))'>
1.1.2 EVALUACIÓN DE LA UTILIDAD.

La finalidad básica de este proyecto es el filtrado web, de utilidad en cualquier entorno donde se desee
controlar el tráfico que se realiza entre una estación de trabajo e internet. Aquí entran desde empresas,
centros docentes, locutorios, hogares, etc...
1.1.3 EVALUACIÓN DEL USO.

El uso de la aplicación resultante es muy simple. El administrador sólo ha de iniciar el servidor proxy, y éste
entrará en funcionamiento aplicando las restricciones que tenga establecidas en el fichero de configuración,
y registrando el tráfico que se realice.
Para la configuración del programa y el control del registro, el administrador podrá acceder mediante un
navegador a la interface web de la aplicación. Tendrá acceso a los diferentes menús de configuración y
control, el uso de los cuales es muy intuitivo, y será implementado mediante formularios html.
La aplicación es totalmente transparente para los usuarios.
12
1.2 PROTOCOLOS
Para este trabajo se ha estudiado el protocolo HTTP, imprescindible para la navegación en internet. El
protocolo HTTP es el encargado de la comunicación y el transporte de los documentos HTML leídos por los
navegadores.
1.2.1 PROTOCOLO HTTP.
1.2.1.1 Introducción
HTTP (Hiper Text Transfer Protocol o Protocolo de Transferencia de Hipertexto) es el lenguaje de
comunicación utilizado en Internet para que los clientes y los servidores puedan comunicarse entre sí.
HTTP es un protocolo a nivel de aplicación que se utiliza en sistemas de información para el intercambio de
datos entre los mismos, y viene siendo utilizado por el www desde 1990.
La primera versión HTTP/0.9 era un protocolo destinado sólo a transferir datos, y rápidamente fue mejorada
a la versión HTTP/1.0, definida en la RFC 1945 en 1996, y que la dota de capacidades que van más allá de la
simple transferencia de hipertexto, permitiendo mensajes tipo MIME, con meta información sobre los datos
transferidos y nuevas extensiones en las cabeceras y códigos de error.
Sin embargo, HTTP/1.0 no tiene en consideración las necesidades de conexiones persistentes, caché,
proxies, seguridad, sistemas que necesitan conocer la capacidad real del otro comunicante, etc... para lo
cual se ha desarrollado el protocolo HTTP/1.1, definido en el año 1999 en la especificación RFC 2610 , y
actualizado en junio de 2007 en la RFC2610bis.
1.2.1.2 Características
•Arquitectura cliente-servidor:
El servidor, una aplicación que permanece a la espera de conexiones generalmente a través del
puerto 80 , responde a las peticiones solicitadas por la aplicación cliente. El protocolo usado
mayoritariamente para la conexión es el TCP.
•Sin estado:
No se conserva la información de una petición a otra, aunque en la práctica se utilizan métodos
que permiten guardar datos sobre conexiones anteriores, como por ejemplo las cookies.
•Localización universal:
El protocolo usa referencias dadas por URI.
•Datos:
HTTP usa los tipos MIME (Multipart Internet Mail Extension).
13
1.2.1.3 Peticiones (Request) HTTP

Una petición HTTP, en su forma simple sería de la siguiente manera:
método <SP> URI <SP> versión <CRLF>
El método le indica al servidor lo que ha de hacer con el URI, y la versión como su nombre indica es el
número de versión del protocolo que el cliente implementa. HTTP/1.1 incorpora ocho tipos de peticiones
(tabla 1.2.1.x), aunque sólo obliga a implementar GET y HEAD. El resto son opcionales, pero los servidores
que los ejecuten han de cumplir sus especificaciones. HTTP/1.0 sólo implementaba GET, POST y HEAD, que
son los más utilizados.
A continuación de la versión, se añade un mensaje compatible con MIME, con los parámetros de la petición,
datos del cliente y otros campos con datos opcionales, para el servidor.
Petición Descripción breve
GET Retorna el recurso solicitado de la URL pedida.
Sólo retorna la información de la cabecera. HEAD es más rápido que
GET, ya que se envía menos información. Se usa para ver si el documento
HEAD solicitado ha cambiado desde la última vez que se accedió a él, cuando se
usa caché. Si es el mismo, la copia de la caché es usada de nuevo, sino se
tiene que recuperar la versión actual con el método GET.
Es usado para enviar datos del cliente al servidor. Los datos del cuerpo
de la solicitud se enviarán al URI especificado. Este URI será una
POST
referencia a una aplicación que procesará los datos de alguna manera,
típicamente será un programa CGI.
PUT Envía el recurso indicado en la URL del cliente al servidor.
OPTIONS Solicita información sobre las opciones de comunicación del servidor.
TRACE Permite al cliente ver lo que recibe el servidor.
DELETE Pide al servidor que borre el recurso URL solicitado
CONNECT Para comunicaciones con SSL
Ilustración 1: Tabla peticiones HTTP
1.2.1.4 Respuestas (Response) HTTP

Una petición HTTP, en su forma simple sería de la siguiente manera:
versión <SP> código <SP> descripción <CRLF>
Incluye la versión del protocolo, un código de éxito o de error y la descripción del código anterior. A
continuación de la descripción viene un mensaje compatible MIME con información sobre el servidor, meta
información sobre el URI solicitado y otras opciones.
Los posibles códigos de estado se identifican con números de tres cifras y se clasifican en cinco grupos:
1.Números del estilo 1XX que representan mensajes de tipo informativo.
2.Números del estilo 2XX que indican que se completó satisfactoriamente la solicitud del cliente.
3.Números del estilo 3XX que indican que la solicitud fue redirigida.
4.Números del estilo 4XX que indican un error en la solicitud del cliente.
5.Números del estilo 5XX que indican un error en el lado del servidor.
14
La tabla 1.2.1.4 muestra los códigos más usuales.
Código Descripción
200 OK El servidor ha enviado la información solicitada.
204 NO CONTENT El cuerpo de la respuesta está vacío.
301 MOVED El URI solicitado no está en el servidor. Ha sido movido a
PERMANENTLY otro sitio.
400 BAD REQUEST Error de sintaxis en la petición del cliente.
Indica que el documento solicitado no está disponible,
404 NOT FOUND
porque el URI ha sido mal escrito o la página no existe ya.
500 INTERNAL
Error interno en el servidor.
SERVER ERROR
Ilustración 2: Códigos respuestas HTTP
1.2.1.5 Cabeceras HTTP

La cabecera define la información que se intercambia entre cliente y servidor dándole flexibilidad al
protocolo. Estas líneas permiten que se envíe información descriptiva en la propia transacción, permitiendo
cosas como la autenticación o identificación de usuarios.
La sintaxis de una línea simple de encabezado es la siguiente:
Nombre del campo: Valor
Los diferentes campos de las cabeceras se clasifican en varios grupos:
•Generales:
Son aquellos que tienen aplicación tanto para mensajes de peticiones como de respuestas, pero
que no se aplican al recurso transferido, sino sólo al mensaje.
•De entidad:
Contienen información relacionada con el recurso que se envía.
•De solicitud:
Son utilizados por el cliente para enviar información adicional al servidor.
•De respuesta:
Utilizados por el servidor para enviar información adicional al cliente.
HTTP dispone de un mecanismo de extensión que posibilita la inclusión de campos no estandarizados en las
cabeceras. Si una implementación del protocolo no reconoce un determinado campo, sólo ha de ignorarlo, o
retransmitirlo tal y como está, si se trata de un servidor intermediario.
15
1.3 LENGUAJE HTML
El HyperText Markup Language (HTML) es un lenguaje de marcas utilizado para crear documentos que nos
permiten representar contenidos de manera enriquecida, referenciar otros documentos o recursos,
implementar formularios, y mucho más.
Actualmente proporciona funciones muy avanzadas que permiten crear páginas de contenido muy
complejo. Se ha especificado también un nuevo lenguaje de marcas compatible con HTML, el XHTML
( Extensible Hipertext Marhup Language) que es una versión más estricta de HTML y compatible con el
estándar XML, y cuya última especificación es la recomendación 1.1 del W3C.
La última especificación de HTML es la 4.01 de 24 de Diciembre de 1999 que define la estructura que han
de cumplir estos documentos.
1.3.1 ESTRUCTURA DE LOS DOCUMENTOS HTML

Un documento HTML se estructura en tres secciones:
• Una línea conteniendo información sobre la versión de HTML que cumple el documento
• Una cabecera de declaraciones ( head) que contiene definiciones sobre el documento.
• El cuerpo (body) donde reside el contenido del documento.
Para especificar la estructura y los contenidos se utilizan las etiquetas HTML (tags), que se escriben entre
los caracteres < TAG > principio de etiquetado y </TAG> final de etiquetado .
Pueden existir espacios en blanco antes o después de cada sección, pero la cabecera y el cuerpo han de
encontrarse entre las etiquetas <html> y </html>.
Existe una gran variedad de etiquetas HTML, pero para el desarrollo de esta aplicación es vital la
localización de la cabecera, donde residirá la información referente a los códigos ICRA, en aquellas páginas
que cumplan este sistema de etiquetado.
Dentro de la cabecera existe la posibilidad de incorporar meta datos, de manera que el autor del
documento puede informar sobre los datos del contenido y otros recursos accesibles.
Los documentos que incorporan el sistema de etiquetado ICRA, incluirán el tag META dentro de la cabecera,
de la siguiente forma:
<HEAD>
<META HTTP-EQUIV=”pics-label” content=”etiquetas_ICRA”>
……..
</HEAD>
16
1.3.2 FORMULARIOS HTML
Un formulario HTML posibilita al usuario enviar información a través del navegador hacia la aplicación
cliente. Como la interface del programa estará implementada con formularios HTML, también es necesario
acceder a los datos retornados por estos.
Las etiquetas básicas de los formularios HTML, son:

• ACTION :
Esta etiqueta indica el destino de los datos a enviar. Principalmente podremos enviar los
datos a una dirección de correo electrónico, o a una dirección HTTP.
• METHOD :
Esta etiqueta indica si será un método GET o POST.
• NAME :
Asigna un nombre al formulario.
• ENCTYPE :
Especifica el tipo de codificación a utilizar para el envío.
Los elementos básicos de los formularios, que nos permitirán introducir los datos a enviar son:
• INPUT :
Es el campo de entrada más utilizado. Existen muchos tipos de elementos INPUT, que son
especificados por el atributo TYPE. El más importante probablemente sea el tipo SUBMIT, pues es el
que realiza la función de aceptación y envío de los datos.
• SELECT :
Nos permite seleccionar una o más, entre varias opciones.
• TEXTAREA :
En este tipo de campo el usuario puede introducir múltiples líneas de texto.
17
2 ANÁLISIS.
2.1 REQUISITOS.
Esta aplicación ha cumplir los siguientes requisitos:
Será programada en JAVA, y funcionará sobre cualquier sistema operativo que tenga instalada una
JVM (Java Virtual Machine), que puede ser descargada desde el sitio web de Sun Microsystems.
La aplicación se iniciará al arrancar el sistema, y permanecerá a la espera de solicitudes por parte de
las aplicaciones cliente.
Al recibir una petición, primero aplicará el filtrado de puertos.
Si es a un puerto permitido, seguirá los siguientes pasos:
Comprobará si el destino está en la lista de dominios registrados. Si está registrado puede estar
prohibido o permitido. Si está prohibido denegará el servicio. Si está permitido no realizará filtrado
alguno.
Si el dominio no está registrado en la lista de dominios, comprobará si la URL contiene alguna
palabra prohibida, y si no es así solicitará el recurso que le ha pedido la aplicación cliente y al
recibirlo:
■Comprobará si tiene etiquetado ICRA, y si es así validará los códigos para determinar si esa
página es accesible para el usuario de la aplicación.
■Si no tiene etiquetado ICRA habrá de comprobar el cuerpo del mensaje, para determinar si es
o no accesible al usuario de la aplicación.
■Si se rechaza el recurso lo notificará a la aplicación cliente, y si se acepta se lo retransmitirá.
Si el usuario es administrador, no se realiza filtrado de ningún tipo, ni se registra sus peticiones al
web.
Se registrarán todas las peticiones de los usuarios no administradores.
Una vez realizado esto quedará de nuevo a la espera de otra solicitud.
18
2.2 DOMINIO.
En una primera aproximación podemos diferenciar las siguientes clases del dominio de la aplicación:
Ilustración 3: Modelo del dominio
2.3 NEGOCIO.
El diagrama de casos de usos del modelo de negocio sería:
Ilustración 4: Casos de usos del modelo de negocio
19
2.4 GLOSARIO DEL MODELO DE NEGOCIO.
Usuario:
Actor usuario del equipo en el que corre nuestra aplicación, cuya actividad a través de internet se
pretende filtrar y registrar.
Administrador:
Actor que es también usuario, pero además con permisos para modificar la configuración de la aplicación, o
sea su modo de funcionamiento, y visualizar y modificar el registro del filtrado.
Servidor:
Es la parte de nuestra aplicación que se encarga de ejecutar el filtrado.
Petición:
Es la solicitud de un recurso de internet, por parte del cliente o navegador al servidor, y ejecutada por un
usuario.
Permiso usuario:
A efectos de permisos, en nuestra aplicación un usuario podrá ser administrador, o no. El servidor filtrará
todas las peticiones de aquellos usuarios que no sean administradores.
Puerto:
Interface lógica a través de la que se comunica una aplicación. Están numerados del 0 al 65535 y
clasificados en tres grupos:
1 – Puertos bien conocidos: del 0 al 1023
2 – Puertos registrados: del 1024 al 49151
3 – Puertos dinámicos o privados : del 49152 al 65535
Dominio:
Nombre que identifica un equipo o conjunto de ellos en internet, de manera más fácil que si lo hacemos por
su dirección IP.
Códigos ICRA:
Listado de códigos que definen el tipo de contenido de una página web.
Lista Dominios:
Lista de dominios registrados, que serán inaccesibles si son prohibidos, o no filtrados si son permitidos.
20
Lista Palabras:
Lista de palabras, cuya aparición en el contenido de un recurso provocará que sea inaccesible al usuario.
Registro:
Listado de los recursos solicitados por los usuarios, sólo si la petición ha sido bloqueada a consecuencia del
filtrado, guardando la información de la hora y tiempo de conexión para cada una de ellas.
2.5 DOCUMENTACIÓN TEXTUAL DE LOS CASOS DE USO.

Los casos de uso iniciar cliente y crear petición del actor usuario, no tienen relevancia desde el punto de
vista de nuestra aplicación, ya que son ajenos a la misma, y sólo han sido reflejados en el modelo de
negocio para una más fácil visualización del mismo. La petición es el principal parámetro de entrada en
nuestro programa, pero es creada de forma totalmente ajena a él.
Caso de uso: “Iniciar Servidor”
-Funcionalidad: Pondrá en marcha la aplicación de filtrado.

-Actor: Administrador
-Precondición: La aplicación no está ya en marcha.
-Postcondición: La aplicación ya está en funcionamiento.
-Aclaración: Este caso de uso puede ser obviado si configuramos el sistema para que la aplicación
arranque al iniciarse el sistema operativo del equipo, que es la opción preferente, pero de no ser así, tendrá
que ser el Administrador quién la inicie a voluntad.
Caso de uso: “Administrar usuarios”
-Funcionalidad: Dar de alta usuarios y adjudicarles permisos.

-Actor: Administrador.
-Precondición: Identificarse como Administrador.
-Postcondición: Listado de usuarios actualizado.
Caso de uso: “Administrar registro”
-Funcionalidad: Revisar el registro de actividades de los usuarios y mantenerlo. Dependiendo del volumen
de datos registrados, habrá de limpiar el fichero del registro y optar por guardar los datos en otra ubicación,
o eliminarlos.
-Postcondición: Fichero de registro actualizado.
Caso de uso: “Administrar Dominios”
-Funcionalidad: Modificar lista de dominios prohibidos.

21

-Postcondición: Lista de dominios prohibidos actualizada.
Caso de uso: “Administrar ICRA”
-Funcionalidad: Modificar listado de códigos ICRA, cuya aparición en un recurso provocará su denegación en
caso de filtrado.
-Postcondición: Lista de códigos ICRA actualizada.
Caso de uso: “Administrar Lista Palabras”
-Funcionalidad: Modificar listado de palabras prohibidas, cuya aparición en un recurso provocará su

denegación en caso de filtrado.
-Postcondición: Listado de palabras prohibidas actualizado.
Caso de uso: “Comprobar petición”
-Funcionalidad: Comprobar si una petición detectada ha de ser denegada o no.

-Casos de uso relacionados: Comprobar permisos usuario, Comprobar puerto, Comprobar dominio,
Comunicar resultado
-Actor: Servidor.
-Precondición: El usuario ha creado una nueva petición.
-Postcondición: Si es denegada se le comunica al usuario ejecutando el caso de uso Comunicar resultado. Si
se acepta se inicia el caso de uso Solicitar recurso.
Caso de uso: “Comprobar permisos usuario”
-Funcionalidad: Comprobar si el usuario del equipo está en la lista de usuarios y cual es su nivel.
-Casos de uso relacionados: Comprobar petición , Comunicar resultado, Solicitar recurso
-Actor: Servidor.
-Precondición: Se está ejecutando el caso de uso Comprobar petición.
-Postcondición: Se le comunica al caso de uso Comprobar petición el nivel al que pertenece el usuario.
Caso de uso: “Comprobar dominio”
-Funcionalidad: Comprobar si el dominio al que se refiere la petición está en la lista de dominios prohibidos.
-Casos de uso relacionados: Comprobar petición.
-Actor: Servidor.
-Postcondición: Se le comunica al caso de uso Comprobar petición si el dominio está en la lista negra o no.
22
Caso de uso: “Comprobar puerto”
-Funcionalidad: Comprobar si el puerto de destino de la petición está en la lista de puertos permitidos.

-Casos de uso relacionados: Comprobar petición .
-Actor: Servidor.
-Postcondición: Se le comunica al caso de uso Comprobar petición si el puerto está permitido.
Caso de uso: “Solicitar recurso”
-Funcionalidad: Solicitar recurso demandado en la petición, al web.

Casos de uso relacionados: Comprobar petición, Comunicar resultado,
-Actor: Servidor.
-Precondición: Se ha ejecutado el caso de uso Comprobar petición.
-Postcondición: Se obtiene del web el recurso solicitado. Si no se obtiene se le comunicará al usuario
ejecutando el caso de uso Comunicar resultado.
Caso de uso: “Comprobar recurso”
-Funcionalidad: Aplicar los filtros al recurso obtenido del web.

-Casos de uso relacionados: Comprobar ICRA, Comprobar contenido, Retransmitir recurso, Comunicar
resultado.
-Actor: Servidor.
-Precondición: Se ha obtenido un recurso solicitado al web.
-Postcondición: Si el recurso pasa los filtros, se ejecutará el caso de uso Retransmitir recurso, si no los pasa
se ejecutará el caso de uso Comunicar resultado.
Caso de uso: “Comprobar ICRA”
-Funcionalidad: Aplicar el filtro de códigos ICRA al recurso obtenido del web.

-Casos de uso relacionados: Comprobar recurso.
-Actor: Servidor.
-Precondición: Se está ejecutando el caso de uso Comprobar recurso.
-Postcondición: Se le comunica al caso de uso Comprobar recurso si ha pasado el filtro o no.
Caso de uso: “Comprobar contenido”
-Funcionalidad: Comprobar si en el contenido del recurso recibido hay palabras de la lista de prohibidas.
-Actor: Servidor.
-Precondición: Se está ejecutando el caso de uso Comprobar recurso.
-Postcondición: Se le comunica al caso de uso Comprobar recurso la existencia o no de palabras prohibidas.
Caso de uso: “Retransmitir recurso”
-Funcionalidad: Retransmitir al cliente el recurso que solicitó, una vez filtrado.

23
-Actor: Servidor.
-Precondición: Se ha ejecutado el caso de uso Comprobar recurso.
-Postcondición: Se le retransmite un recurso permitido al cliente.
Caso de uso: “Comunicar resultado”
-Funcionalidad: Comunicar al usuario el resultado negativo a su petición, y una breve explicación.

-Actor: Servidor.
-Precondición: Se han ejecutado cualquiera de los casos de uso Comprobar petición, Solicitar recurso,
Comprobar recurso.
-Postcondición: Se le comunica al usuario la denegación a su petición, y una breve descripción del motivo.
Caso de uso: “Registrar petición”
-Funcionalidad: Insertar una nueva entrada en el registro para guardar los datos de la petición, haya sido
aceptada o no.
-Actor: Servidor.
-Precondición: Ha finalizado la ejecución del filtrado de una petición.
-Postcondición: Se ha insertado una nueva entrada en el registro de peticiones.
24
2.6 ESPECIFICACIÓN DE LAS CLASES.
2.6.1 IDENTIFICACIÓN DE LAS CLASES DE IDENTIDAD.

Para la identificación de las diferentes clases de entidad, repasamos el modelo del dominio y encontramos:
•Usuario. Esta clase sí será de entidad, y representará un usuario, con los atributos:
Onombre: string.
Oclave: string.
Oadministrador: boolean.
•Administrador. Aunque en el modelo del dominio la representábamos como heredera de Usuario, la
obviaremos, y estará representada como un atributo de la clase Usuario, que nos dirá si ese usuario es
administrador o no.
•ListaUsuarios. Esta clase sí es de entidad, y además ha de ser persistente, para poder guardar en un
fichero “ListaUsuarios” la información de los mismos. Sus atributos:
 listausuarios: Lista de Usuario.
•ListaPalabras. Esta clase también es de entidad y persistente. En el fichero “listapalabras” se
guardará la lista de palabras prohibidas. Sus atributos:
O listaPalabras: Lista de string.
•codigoICRA. Esta clase también es de entidad. En el fichero “listacodigos” se guardará la lista de
códigos. Sus atributos:
O codigo: string.
O prohibido: bolean.
O descripción: string
•ListaICRA. También es de entidad y persistente. En el fichero “listacodigos” se almacenará la lista de

códigos ICRA. Sus atributos:
O listaCodigos: Lista de string.
•ListaPuertos. Clase de entidad, que será persistente en el fichero “listapuertos”. Sus atributos:
O listaPuertos: Lista de integer.
•Dominio. Clase de entidad, con los atributos:
O dominio: String
O prohibido: boolean.
•ListaDominio. En esta clase de entidad, representamos la lista de dominios registrados, y será
persistente en el fichero “listadominios”. Sus atributos:
O listaDominios: Lista de Dominio.
•Peticion. En esta clase de entidad, representamos los datos a registrar de cada petición, haya sido
exitosa o no, y que será persistente en el fichero “registro”. Sus atributos:
O resultado: boolean.
O dia: long.
O hora:long.
O duracion: long
O recurso: String.
O puerto: integer
25
O usuario: String
•Registro. En esta clase de entidad, representamos la lista de peticiones registradas, y será
persistente en el fichero “registro”. Sus atributos:
O listaPeticiones: Lists de string.
Con esto nos queda un diagrama de clases como el de la figura 2.6.1.1.
Ilustración 5: Diagrama de clases de entidad
26
2.7 DIAGRAMAS DE COLABORACIÓN.

Realizaremos los diagramas de colaboración, para los casos de uso descritos hasta ahora.
Administrar usuarios:
En este caso de uso el usuario a través del navegador solicita al servidor la página del menú de la
aplicación, que no es más que un formulario html. El servidor comprueba si ese usuario es administrador, y
si es así se la envía al navegador, y el usuario solicita la página de control de usuarios. El servidor le envía
al navegador el formulario de control de usuarios, y el usuario administrador lo rellena como crea adecuado,
para volvérselo a enviar al servidor, que con los datos recibidos actuará sobre el fichero “listauarios”.
Ilustración 6: Colaboración caso de uso Administrar usuarios
Administrar registro:
Es igual que el caso de uso anterior hasta el momento en que el usuario administrador rellena el
formulario solicitando la página, en este caso, de control del registro. El servidor se la envía al navegador y
el usuario a través de ella podrá solicitar la lista completa de registros, borrar algunos seleccionados, o
borrarlos todos.
Ilustración 7: Colaboración caso de uso Administrar registro
Administrar dominios:
27
Es igual que los anteriores pero ahora el usuario solicita la página de control de dominios . El servidor se
la envía al navegador y el usuario por medio de ese formulario podrá ver el listado, añadir y modificar
dominios censados.
Ilustración 8: Colaboración caso de uso Administrar dominios
Administrar códigos ICRA:
Es igual que los anteriores pero ahora el usuario solicita la página de control de códigos ICRA. Lo único que
cambia con respecto al diagrama anterior es que en este caso el objeto a manipular es la lista de códigos
ICRA “listaCodigos”, así que no representaremos su diagrama de colaboración. Con el formulario de control
de códigos ICRA, el usuario podrá ver el listado de códigos, añadir nuevos, modificar y borrar.
Administrar lista de palabras:
Igual que los anteriores pero ahora el usuario solicita la página de control de palabras prohibidas. Lo único
que cambia con respecto al diagrama anterior es que en este caso el objeto a manipular es la lista de
palabras prohibidas “listaPalabras”, así que tampoco lo representaremos. Con el formulario de control de
palabras prohibidas, el usuario podrá ver el listado de palabras, añadir nuevas y modificar o borrar.
Comprobar petición:
En este caso de uso el servidor recibe una petición de un recurso de internet, y ha de comprobar en primer
lugar si el usuario es administrador o no. Si no lo es entonces comprobará si el dominio al que va dirigida
está censado y si es prohibido o no. Si está censado como prohibido dará mensaje de “pagina no accesible”
al navegador. Si está censado como no prohibido se limitará a solicitar el recurso al web, y retransmitir al
navegador lo que le llegue. Si el dominio no está en la lista, solicitará el recurso al web e irá comprobando si
existen palabras prohibidas comparándolo con la lista ”listaPalabras”.
28
Ilustración 9: Colaboración caso de uso Comprobar petición
Comprobar permisos usuario:
Este caso de uso extiende de los casos de uso “Comprobar petición” y los relativos a la administración.
El servidor consulta la lista de Usuarios, para comprobar si el usuario actual es administrador o no. Es muy
simple y no lo representaremos aquí.
Comprobar dominio:
Este caso de uso extiende del caso de uso “Comprobar petición”.
El servidor consulta la lista de Dominios, para comprobar si el dominio al que pertenece el recurso solicitado
está censado y si está prohibido o no. También es simple y no lo representaremos.
Comprobar puerto:
Al igual que el anterior, este caso de uso extiende del caso de uso “Comprobar petición”.
El servidor consulta la lista de Puertos, para comprobar si el puerto solicitado está permitido o no. También
es muy simple y no lo representaremos.
Solicitar recurso:
Este caso de uso se ejecuta tras el de “Comprobar petición”. El servidor se limita a solicitar al web el recurso
de la petición. Si se recibe un código “200” indicará que ha recibido la página correctamente, e irá
guardando los datos que reciba, para después ejecutar el caso de uso “Comprobar recurso”.
29
Comprobar recurso:
En este caso de uso el servidor comprobará si el contenido de “pagina”, la página recibida, pasa los filtros
de los códigos ICRA y de las palabras prohibidas.
Si la página contiene códigos ICRA, los analiza y actuará según el resultado, y ya no será necesario filtrar
por palabras.
Ilustración 10: Colaboración caso de uso Comprobar recurso
Comprobar ICRA:
Este caso de uso extiende al anterior “Comprobar recurso” y como sólo se ejecutaría dentro de él, lo
eliminaremos.
Comprobar contenido:
Igual que le sucede al anterior, sólo se ejecuta dentro del caso de uso “Comprobar recurso”, así que lo
eliminaremos también.
Retransmitir recurso:
Este caso de uso sólo refleja la ejecución por parte del servidor del envío de la página recibida desde
internet, hacia el cliente navegador. Es muy simple y no lo representaremos.
Comunicar resultado:
En este caso de uso el servidor comunica al cliente un código “400”, con “Página no encontrada”.
Es muy simple también.
Registrar petición:
En este caso de uso el servidor una vez completados todos los pasos, guardará en el fichero “registro” los
datos del resultado de la petición. Básicamente será registrar si se denegó o no la petición, el día y la hora
de la petición, el tiempo que duró la conexión, el URI del recurso, el puerto usado y el usuario que la realizó.
30
2.8 INTERFACE DE USUARIO.

Para esta aplicación, el único usuario que interactúa a través de una interface es el usuario-administrador,
para la configuración del filtrado y acceso a la información del registro. El punto de acceso a la aplicación,
es cualquier navegador web, mediante la solicitud de los ficheros de configuración.
Todas las pantallas son documentos html, y en lugar de plantear el esquema de las diferentes pantallas,
realizamos directamente su diseño, pues son muy sencillas:
Menú inicial:
Es el punto de acceso a todas las demás pantallas y opciones del programa. El campo opciones es una lista
desplegable donde el administrador seleccionará: Administrar usuarios, Administrar lista negra, Administrar
dominios, Administrar códigos ICRA o Administrar el registro.
Ilustración 11: Pantalla Menu Inicial
Se accede a este menú desde el del menú inicial y permite optar por visualizar la lista de usuarios, añadir
uno nuevo, y eliminar o modificar uno existente.
Ilustración 12: Pantalla Administrar Usuarios
31
Administrar lista negra:
Se accede a este menú a través del menú inicial. En el se podrá optar por ver el listado de palabras
prohibidas, añadir palabras nuevas y borrar existentes.
Ilustración 13: Pantalla Administrar Lista Palabras
Administrar dominios:
Igual que los anteriores, para acceder a él ha de ser a través del menú inicial. En este menú se podrá optar
por ver el listado de dominios censados, añadir nuevos y modificar o borrar existentes.
Ilustración 14: Pantalla Administrar dominios
32
Administrar códigos ICRA:
Se accede a esta pantalla también a través del menú inicial. En ella seleccionaremos si queremos visualizar
la lista de códigos ICRA que tenemos en el fichero “listacodigos”, añadir nuevos códigos y borrar o
actualizar alguno existente ya.
Ilustración 15: Pantalla Administrar Códigos
Administrar registro:
Igual que todas las anteriores, será accesible por medio del menú inicial. En esta pantalla las opciones serán
visualizar un listado con todas las entradas del registro tal y como esté en ese momento, eliminar entradas
por fecha, y eliminar todas las entradas actuales, o lo que es lo mismo, borrar el registro.
Ilustración 16: Pantalla Administrar Registro
33
Administrar puertos.
Desde esta pantalla accederemos a la configuración de los puertos que deseemos permitir para los usuarios
filtrados por el proxy. Aquí podremos ver la lista de puertos permitidos, añadir nuevos y borrar otros.
Ilustración 17: Pantalla Administrar Puertos
Además de las pantallas anteriores, existirán otras más simples, que servirán para informar al usuario del
resultado de cada transacción, y que no detallamos aquí, pues serán meros mensajes a través del
navegador.
34
3 DISEÑO
3.1 DISEÑO DE LOS CASOS DE USO

Cuando el usuario escoge una opción del menú inicial, envía al servidor ( método POST del protocolo HTTP)
el formulario rellenado con los siguientes valores posibles para el campo “opciones”:
“1” Administrar usuarios
“2” Administrar lista palabras
“3” Administrar dominios
“4” Administrar códigos ICRA
“5” Administrar puertos
“6” Administrar registro
El servidor envía la página “administrarusuarios.html” al cliente, y el usuario rellena este nuevo formulario.
En él hay tres campos para introducir el nombre del usuario ( campo “nombredelusuario”), su clave (campo
“clave usuario”) y si es administrador o no (campo “administrador”), así como las siguientes opciones:
Ver lista.
 Si selecciona esta opción enviará el formulario con el campo “opcion” al valor “1” y el
servidor al recibirlo creará un documento html en el cual escribirá el contenido del fichero
“listausuarios” y se lo enviará al cliente.
Añadir.
 Con esta opción enviará el campo “opcion” con el valor “2”, y el servidor leerá los campos
“nombredelususario”, “clave usuario” y la opción “administrador”, para con ellos instanciar un
objeto de la clase Usuario, y añadirlo al fichero “Lista de Usuarios”.
Borrar.
 Si selecciona esta opción el campo “opcion” toma el valor “3”, y el servidor borrará del fichero
“listausuarios” el objeto Usuario cuyo atributo nombre sea igual al valor del campo
“nombredelusuario”.
Modificar.
 Con esta opción el campo “opcion” valdrá “4”, y el servidor sabrá que ha de actualizar los
datos del usuario cuyo nombre sea igual al valor del campo “nombredelusuario”.
En el caso de que exista algún error, el servidor lo comunicará mediante un mensaje.
35
Administrar lista negra.
El servidor envía la página “administrarpalabras.html” al cliente, y el usuario rellena este nuevo formulario.
En él hay un campo para introducir la palabra ( campo “palabra”), así como las siguientes opciones:
Ver lista
“listapalabras” y se lo enviará al cliente.
Añadir
 Con esta opción enviará el campo “opcion” con el valor “2”, y el servidor leerá el campo
“palabra”, para añadirlo al fichero “listapalabras”.
Borrar
“listapalabras” aquella que sea igual al valor del campo “palabra”.
Administrar dominios.
El servidor envía la página “administrardominios.html” al cliente, y el usuario rellena este nuevo formulario.
En él hay dos campos para introducir la URL del dominio ( campo “urldominio”) y validar si está prohibido o
permitido, así como las siguientes opciones:
Ver lista
“listadominios” y se lo retransmitirá al cliente.
Añadir
 Con esta opción enviará el campo “opcion” con el valor “2”, y el servidor leerá el valor de los
campos “urldominio” y “prohibido”, para con ellos instanciar un objeto de la clase URL y
añadirlo al fichero “listadominios”.
Modificar
“urldominio” y “prohibido”, para localizar el objeto del fichero “listadominios” que tenga el
atributo dominio con el mismo valor que del campo “urldominio”, y actualizar su campo
“prohibido” al nuevo valor.
36
Borrar
“listadominios” aquel objeto Dominio cuyo atributo dominio sea igual al valor del campo
“urldominio”.
Administrar códigos ICRA.
El servidor envía la página “administrarcodigos.html” al cliente, y el usuario rellena este nuevo formulario.
En él hay tres campos para introducir el código ICRA (campo “codigo”), su descripción ( campo
“descripcion”) y validar si está prohibido o permitido, así como las siguientes opciones:
Ver lista
“listacodigos”, para enviárselo al cliente.
Añadir
campos “codigo”, “descripcion” y “prohibido”, para con ellos instanciar un objeto de la clase
Codigo y añadirlo al fichero “listacodigos”.
Modificar
 Con esta opción enviará el campo “opcion” con el valor “2”, y el servidor leerá los campos
“codigo”, “descripcion” y “prohibido”, para localizar el objeto del fichero “listacodigos” que
tenga el atributo codigo con el mismo valor que del campo “codigo”, y actualizar sus campos
“descripcion” y “prohibido” con los nuevos valores.
Borrar
“listacodigos” aquel objeto Codigo cuyo atributo codigo sea igual al valor del campo “codigo”.
37
Administrar puertos.
El servidor envía la página “administrarpuertos.html” al cliente, y el usuario rellena este nuevo formulario.
En él hay un campo para introducir el número de puerto ( campo “numeroPuerto”), así como las siguientes
opciones:
Ver lista
“listapuertos” y se lo enviará al cliente.
Añadir
“numeroPuerto”, para añadirlo al fichero “Lista de puertos”, si no existe ya.
Borrar
“listapuertos” aquel cuyo número sea igual al valor del campo “numeroPuerto”.
Administrar registro.
El servidor envía la página “administrarregistro.html” al cliente, y el usuario rellena este nuevo formulario.
En él hay dos campos para introducir el día de inicio ( campo “fechaInicio”) y el día final (campo “fechaFin”)
para la selección de los registros de peticiones,así como las siguientes opciones:
Ver lista
servidor leerá los valores de “fechaInicio” y “fechaFin” para con ellos seleccionar los registros
del fichero “registro”, de las peticiones realizadas durante esos días, y crear un documento html
en el cual escribirá el contenido de los mismos y se lo enviará al cliente.
Borrar
campos “fechaInicio” y “fechaFin”, para con ellos localizar los registros del fichero “registro” de
las peticiones realizadas esos días y eliminarlos del mismo.
Borrar TODO
 Con esta opción enviará el campo “opcion” con el valor “3”, y el servidor borrará todos los
registros del fichero “registro”.
38
3.2 DIAGRAMA ESTÁTICO DEL DISEÑO.
Ilustración 18: Diagrama estático del diseño
39
4 IMPLEMENTACIÓN CON JAVA.
4.1 SOCKETS
Para la comunicación entre servidor y cliente de nuestra aplicación utilizaremos sockets.
Un socket es un punto final de un enlace de comunicación de dos vías, entre dos programas que se ejecutan
normalmente a través de una red, aunque también pueden correr en el mismo equipo.
Un socket queda completamente definido por una dirección IP, un protocolo y un número de puerto.
Existen dos tipos de sockets:
Orientado a la conexión.
Establece una ruta virtual entre el servidor y el cliente, que es fiable, en la cual no hay
pérdida de información ni duplicidad, y en la que los datos llegan en el orden en que se
envían.
El cliente inicia una sesión en el servidor, y éste guarda información sobre el estado del
cliente.
No orientado a conexión.
Se envían datagramas de tamaño fijo. Pueden existir pérdidas de información y los datos no
llegan ordenados. No se guarda información sobre el estado del cliente en el servidor, y así
es más tolerante a fallos.
Para que se establezca la conexión entre cliente y servidor, es necesario que el servidor permanezca a la
escucha en el puerto especificado. Para ello es iniciado el socket del servidor en primer lugar. Cuando un
cliente solicita una conexión a través del puerto donde espera el servidor, éste acepta la petición, y a partir
de aquí ya puede comenzar la transferencia de la información, entre las aplicaciones implicadas.
Cuando acaba la transferencia de información, el cliente cierra su canal o socket, y el servidor puede
permanecer a la espera de otra petición de un nuevo cliente o cerrar su socket también.
En nuestra aplicación es importante que el servidor pueda aceptar peticiones de varios clientes
simultáneamente, y para ello utilizaremos diferentes Threads para cada petición de un cliente nuevo.
4.2 THREADS
Un Thread es un flujo secuencial dentro de un programa o proceso. No puede ejecutarse por sí mismo, sino
siempre dentro de un proceso.
Todos los Threads de un proceso o programa, comparten los mismos recursos ( canales E/S, memoria, etc..),
de esa forma el cambio de contexto entre Threads es mucho más fácil para el sistema que en el caso de
cambio de contexto entre procesos diferentes.
Mientras que los programas de flujo único pueden realizar su tarea ejecutando las subtareas
secuencialmente, un programa multi-Thread permite que cada Thread comience y termine tan pronto como
sea posible. Este comportamiento presenta una mejor respuesta a la entrada en tiempo real.
En nuestro caso, cuando el servidor acepte la conexión de un nuevo cliente, iniciará un nuevo Thread que
será quién se encargue de la comunicación con el cliente, y él volverá a quedar a la espera de nuevas
peticiones.
40
4.3 PERSISTENCIA.
La necesidad de guardar la información, nos lleva a tomar una decisión sobre como realizarlo. Tenemos dos
opciones básicas:
Serialización:
Los objetos señalados como serializable, pueden ser convertidos en una serie de bytes, de manera
que nos permitirá guardarla en cualquier soporte. Para recuperar esos objetos, se realiza una
deserialización.
Bases de datos:
Actualmente las base relacionales (BD) son los sistemas dominantes para el almacenamiento de
datos, pero las diferencias entre el paradigma de la orientación a objetos y el modelo relacional,
obliga a la creación de una capa de persistencia entre la aplicación y la base de datos. La
implementación de esta capa de persistencia podemos realizarla mediante clases Java que mapean
objetos a registros, y al revés, o utilizando un motor de persistencia o ORM, como Hibernate, que
nos evitará escribir todo ese código.
Para nuestra aplicación optaremos por la serialización, por varios motivos:
No nos obliga a instalar un SGBD.
La cantidad de datos a almacenar no es elevada.
Mayor simplicidad.
Cuando instalemos el programa, y en un mismo directorio, copiaremos los ficheros de configuración de la

aplicación, junto con el fichero “proxy.jar”, que es el ejecutable de nuestra aplicación.
Los ficheros de configuración inicialmente contendrán unos datos mínimos, y será el administrador quién
tendrá que mantenerlos actualizados, utilizando para ello la interface del programa.
NOTA: Los ficheros de configuración son simples ficheros de texto, que también pueden ser modificados
directamente con cualquier editor. Queda fuera del alcance de este trabajo dotar a la aplicación de sistemas
de seguridad que impidan la modificación de dichos archivos por usuarios no autorizados.
4.4 API JAVA

Para la implementación del diseño realizado, y tras estudiar el API (Interface de Programación de
Aplicaciones) de Java, se ha decidido la utilización de las clases principales explicadas a continuación.
Del paquete java.net :
ServerSocket:
Esta clase implementa el socket del lado del servidor. Una vez creado ha de permanecer a la escucha en el
puerto especificado, que en esta aplicación será el 8080, hasta que un cliente solicite conectarse con él.
Creamos un objeto con la siguiente llamada al constructor:
socket = new ServerSocket(8080);
41
Socket:
Esta clase implementa la funcionalidad de los sockets. Es la que implementa el socket para el cliente.
Creamos un objeto con la siguiente llamada al construtor:
Socket socket_cli = socket.accept();
Thread:
La forma más directa para hacer un programa multi-thread es extender la clase Thread, y redefinir el
método run(). Este método es invocado cuando se inicia el thread (mediante una llamada al método start()
de la clase thread). El thread se inicia con la llamada al método run y termina cuando finaliza éste.
Código de la aplicación donde creamos e iniciamos el thread:

//Y creamos un nuevo hilo (Thread) al que le enviamos como parámetro
//el socket creado con el cliente
ThreadServidor nuevaPeticion=newThreadServidor(socket_cli,esAdmin,peticion);
//Arrancamos el nuevo hilo
nuevaPeticion.run();
Del paquete java.io:
InputStream:
Esta clase abstracta declara los métodos para leer datos desde una fuente concreta y es la clase base de la
mayoría de los flujos de entrada. La usamos cuando obtenemos un objeto DataOutputStream con el método
getOutputStream() de la clase Socket.
OutputStream:
Esta clase abstracta es semejante a la anterior, pero declara los métodos para escribir datos a un flujo de
salida, en nuestro caso un socket. La utilizaremos para obtener un objeto DataInputStream con el método
getOutputStream() de la clase Socket.
DataInputStream:
Esta clase proporciona los métodos necesarios para leer datos primitivos de un flujo de entrada. En nuestra
aplicación será utilizada para leer los mensajes recibidos por el socket con el cliente.
Muestra de código de la palicaicón donde creamos un objeto de esta clase:
//Leemos la petición del cliente
DataInputStream inCliente =
new DataInputStream(socket_cli.getInputStream());
42
DataOutputStream:
Esta clase proporciona los métodos necesarios para escribir datos primitivos en un flujo de salida. En
nuestra aplicación será utilizada para enviar los mensajes por el socket hacia el servidor web.
Extracto de una parte de código de la aplicación donde se crea un objeto DataOutputStream.
//Instanciamos objeto para escribir mensajes al web
DataOutputStream outWeb =
new DataOutputStream(socketWeb.getOutputStream());
FileInputStream:
Esta clase nos proporciona los métodos necesario para la lectura de datos desde un fichero. La utilizamos
para la lectura de los ficheros de configuración de la aplicación.
Muestra de código de la aplicación donde es instanciado un objeto de esta clase, es leído el fichero y
enviados los datos al cliente:
fileIn = new FileInputStream(fitxer);
//Leemos el fichero entrado por parámetro
while((bytes = fileIn.read(buffer)) != 1 )
//Y se lo enviamos al cliente
socket_cli.getOutputStream().write(buffer, 0, bytes);
FileOutputStream:
Esta clase nos proporciona los métodos necesario para la escritura de datos en un fichero. La utilizamos
para escribir y crear los ficheros de configuración de la aplicación.
Muestra de código de la aplicación donde es instanciado un objeto de esta clase, y escribimos en el los
datos de un dominio:
FileOutputStream outFile = new FileOutputStream(fichero);
outFile.write((dominio.toString()+"\r\n").getBytes());
43
4.5 CLASES
A continuación se explican con detalle las diferentes clases que han resultado durante la implementación
del diseño.
Servidor:
Es la clase principal e inicial del programa. Su especificación:
Ilustración 19: Clase Servidor
En primer lugar instanciará un objeto de la clase CrearFicheros, que se explica más adelante, y a
continuación crea un ServerSocket en el puerto 8080, permaneciendo a la espera de conexiones por parte
de los clientes. Cuando recibe una petición instancia un objeto de la clase Petición y otro de la clase
ThreadServidor. Al crear el objeto ThreadServidor le pasa por parámetro la nueva Petición y una variable
booleana que indica si el usuario que hace la petición es administrador o no. Una vez realizado esto, queda
a la espera de nuevas peticiones de clientes.
ThreadServidor:
Es la clase que ejecuta todo el proceso de comunicación con el cliente y con los servidores externos, así
como el filtrado de la misma.
Ya hemos explicado en apartados anteriores el funcionamiento básico de un thread.
En esta clase al ejecutarse el thread, método run(), en primer lugar leemos la petición del cliente, que en
nuestro caso es el navegador del mismo equipo, y extraemos los datos del protocolo HTTP necesarios:
Tipo de petición : que aquí sólo contemplamos GET y POST
URI : que también puede ser el nombre de uno de los ficheros de configuración de la aplicación.
Extraemos también la última línea de la petición, que será la respuesta en el caso de los
formularios de configuración.
Es importante recalcar que también eliminamos, de las peticiones que nos envía el navegador cliente, las
opciones :
- “Accept-Encoding”: Si recibimos los datos codificados, no podemos comprobar los contenidos.
- “Keep-Alive”: La cambiamos por “Connection: close”, así el servidor web cierra la conexión nada
más acabar el envío de la página solicitada.
44
A partir de este momento hay dos posibilidades:

El usuario es administrador: En este caso si solicita un fichero de configuración, se instancia un objeto de
la clase Menu. Si solicita un recurso de internet se solicita ésta mediante el método conectarWeb(), sin
realizar ningún filtrado.
El usuario no es administrador: En este caso si solicita un fichero de configuración se le negará el acceso.
Si solicita un recurso de internet se ejecutarán los diferentes filtros.
El método conectarWeb() es la base de la comunicación con los servidores de internet. Con los datos
recibidos desde el socket del cliente extraemos el host y el puerto para crear un nuevo socket con el
servidor web, e instanciamos dos objetos, un DataInputStream y otro DataOutputStream , para el
intercambio de datos a través de este nuevo socket.
Enviamos la petición a través del flujo de salida, y vamos almacenado los datos recibidos, mediante el
método read() de la clase DataInputStream, en un array de bytes, la variable ”datos”.
Cuando el método read() devuelve el valor –1, implica que no hay más datos y finalizamos la lectura desde
el socket web.
Al mismo tiempo hemos ido creando un String, la variable “pagina” con los datos recibidos, que será la
que enviaremos a los métodos filtradoICRA() y filtradoPalabras(). Si pasa los filtros, enviaremos la variable
“datos” por el flujo de salida del socket del cliente. Si no pasa los filtros le enviaremos un mensaje de
información conforme la página no ha sido encontrada.
Su especificación:
Ilustración 20: Clase ThreadServidor
45
Menu:
Es la clase que implementa el menú de configuración de la aplicación. Su especificación:
Ilustración 21: Clase Menu
Al constructor de la clase se le pasa por parámetro el socket del cliente (programa navegador). Una vez
instanciado el objeto Menu, se puede ejecutar el método ejecutarMenu, al cual le pasaremos por
parámetros el fichero a manejar, el tipo de petición (GET o POST), la petición misma y un vector que
contendrá los nombres de los ficheros de configuración.
Este método es el que ejecutará las acciones necesarias para la gestión de la configuración del programa
CrearFicheros:
Es la clase que ejecuta la creación de los ficheros de configuración.
Cada vez que se inicia el Servidor, instancia un objeto de esta clase, el cual comprueba si ya existen los
ficheros de configuración. Para comprobar si existen instancia un objeto de la clase File , y si el fichero no
existe lo creará haciendo uso de la clase FileOutputStream. Para la creación de los diferentes ficheros usa
unos parámetros mínimos. Para el fichero “listausuarios” crea un primer usuario con el nombre del
usuario actual, que será administrador con una clave inicial “1000”.
Si el fichero “registro” ya existe comprueba su tamaño. Cuando este fichero, que registra todas las
peticiones que han sido bloqueadas, sobrepasa los 500Kbytes lo renombra como “regBackup” con una
extensión que es el retorno de la función System.currentTimeMillis(), y se crea un nuevo “registro”.
46
Su especificación:
Ilustración 22: Clase CrearFicheros
Usuario:
Esta clase implementa un usuario. Su especificación:
Ilustración 23: Clase Usuario
47
Dominio:
Esta clase implementa un dominio. Su especificación:
Ilustración 24: Clase Dominio
Peticion:
Es la clase que implementa una petición.
Esta clase tiene dos constructores diferentes. El primero es usado por la clase Servidor, para crear un
objeto nuevo con cada petición recibida. Sólo se le pasa por parámetro el nombre del usuario, el resto de
datos son creados automáticamente. El segundo constructor es usado por la clase CrearFicheros para
crear una primera petición ficticia durante la creación del fichero “registro” y necesita que le pasen por
parámetro el nombre del usuario y la url. Su especificación:
Ilustración 25: Clase Peticion
48
CodigoICRA:
Esta clase implementa un código ICRA. Su especificación:
Ilustración 26: Clase CodigoICRA
Lista:
Esta clase implementa una array de strings formados a partir de las cadenas extraídas de los ficheros de
configuración.
Contiene los métodos necesarios para la consulta y modificación del contenido, así como la salvaguarda de
los datos ya modificados, en el mismo fichero.
Su especificación:
Ilustración 27: Clase Lista
49
ListaUsuarios:
Esta clase heredera de “Lista” , implementa métodos específicos para poder creargestionar usuarios. Su
especificación:
Ilustración 28: Clase listaUsuarios
listaCodigos:
Esta clase también es heredera de “Lista”, e implementa la lista de códigos ICRA.
Su especificación:
Ilustración 29: Clase listaCodigos
listaDominios:
Esta clase implementa la lista de dominios registrados. Su especificación:
Ilustración 30: Clase listaDominios
50
4.6 DIAGRAMA DE CLASES

El diagrama de relación de las clases de la aplicación sería:
Ilustración 31: Diagrama de clases
51
4.7 DIAGRAMA DE FLUJO SIMPLIFICADO DE LA APLICACIÓN
Ilustración 32: Diagrama de flujo
52
5 MANUAL DE LA APLICACIÓN.
5.1 INSTALACIÓN
Los archivos necesarios para la instalación, y funcionamiento de la aplicación son:
proxy.jar : Este archivo contiene todas las clases de la aplicación.
Los documentos html que implementan la interface de configuración del programa:
■ menuinicial.html
■ administrarusuarios.html
■ administrarpalabras.html
■ administrardominios.html
■ administrarcodigos.html
■ administrarpuertos.html
■ administrarregistro.html
Para la ejecución del programa es suficiente copiar estos archivos en un mismo directorio, y desde éste
ejecutar: java -jar proxy.jar
Las únicas restricciones son:

El sistema ha tener instalada y configurada una JVM.
El usuario ha de tener permisos de lectura y escritura sobre este directorio.
En cuanto a los navegadores, se ha probado su funcionamiento con Mozilla Firefox 2.0.0.2 y con
Internet Explorer versiones 6 y 7.
Es necesario configurarlos en el apartado “Red” para que utilicen el proxy “localhost” en el puerto 8080.
Con estas condiciones, la aplicación ha sido comprobada, siendo correcto su funcionamiento, en las
siguientes plataformas con la versión “jre1.5.0_06” de JVM :
PC Intel(R) Core(TM)2 CPU T5600 1.83GHz 2GB de RAM

Kernel Linux 2.6.17 UBUNTU 6.10 Edgy
Windows XP SP2
PC Intel Pentium 3 Mobile 1066MHz 512MB de RAM

Windows 2000 SP4
PC Intel Pentium 4 2.80GHz 258MB de RAM

Windows 2000 Professional
Kernel Linux 2.6.17 UBUNTU 6.10 Edgy
53
5.2 GESTIÓN
En el apartado anterior se ha explicado como instalar y ejecutar la aplicación.
Desde el inicio del diseño, se ha contemplado la aplicación como servicio residente del sistema, de manera
que no se le ha dotado de método propio, para finalizarla a voluntad.
Si se desea parar el programa se tendrá que hacer mediante comandos de sistema, y esto será dependiente
de la plataforma donde se esté ejecutando.
Es importante recalcar que la primera vez que se ejecute el programa, al crear el fichero “listausuarios”, se
crea el primer usuario administrador, adjudicándole el nombre del usuario actual del sistema.
La interface de usuario se limita a la gestión de la configuración del filtrado que la aplicación realizará.
Esta gestión será llevada a cabo por los usuarios registrados como administradores por medio de cualquier
navegador web. Para ello bastará con introducir en la barra de direcciones del navegador el nombre del
fichero del menú inicial “menuinicial.html” , y a partir de este menú acceder a las diferentes opciones.
También es posible acceder directamente a cualquiera de los ficheros de configuración, introduciendo su
nombre en el navegador.
Tal y como se especificó durante la fase de diseño, el administrador podrá :
• Añadir, borrar y modificar usuarios.
• Añadir, borrar y modificar dominios registrados.
• Añadir, borrar y modificar palabras prohibidas.
• Añadir, borrar y modificar códigos ICRA.
• Consultar y borrar las peticiones registradas.
Los ficheros iniciales, sólo incorporan los mínimos elementos para la ejecución del programa, por ello, si se
desea un buen filtrado se han de ampliar estos ficheros, incorporando palabras y dominios.
El administrador también tendrá que encargarse del control de los archivos de registro. Como ya se explicó
en el apartado de implementación, cuando el fichero de registro sobrepasa los 500Kbytes se crea un nuevo
fichero “regBackup.xxxxxxxxxxxxx” , donde las “x” son el retorno de la función System.currentTimeMillis(),
y el original queda vacío. Así con el paso del tiempo pueden llegar a ser muy numerosos y ocupar espacio
de disco necesario para otros usos. Queda a cargo del administrador la eliminación de los ficheros antiguos.
54
6 CONCLUSIONES.
La aplicación obtenida cumple con los requisitos que se establecieron desde el inicio.
En cuanto a la gestión del programa, cabe destacar la interface de configuración del mismo, por su sencillez
y funcionalidad.
A medida que se iba desarrollando la aplicación, se hacían patentes posibles funcionalidades y mejoras a
añadir, pero hubieran supuesto una carga de trabajo, que hubiese imposibilitado la entrega en el plazo
previsto.
Destacar también que la creación inicial del plan de trabajo ha sido imprescindible para cumplir el objetivo
final. La obligatoriedad de cumplir los plazos propuestos en el plan de trabajo han supuesto un reparto muy
apropiado de la carga de trabajo que supone este proyecto.
6.1 MEJORAS
✔ La primera de estas mejoras, detectada en un último momento, y no prevista, es la provisión de un

mecanismo para detener la aplicación una vez en marcha. Al utilizar un IDE (Eclipse) durante toda
la fase de desarrollo y pruebas, no se hizo patente esta necesidad.
✔ En un principio se preveía ejecutar un control más estricto a la hora de autentificar a los usuarios
administradores, y por ello la clase Usuario contiene el atributo “clave”, pero durante el desarrollo
del código, se optó por validarlos mediante el atributo “esAdministrador”. Así el atributo “clave” no
es utilizado para la identificación.
✔ En cuanto al filtrado utilizando el etiquetado ICRA, este programa busca los tags de las mismas en
cada página para filtrarlos. Este método no es el más adecuado, puesto que según las
recomendaciones de la organización que regula este sistema de etiquetado, es mejor crear enlaces
en las páginas a ficheros RDF, donde se especifican las etiquetas.
Así si se desea una correcta utilización de estas etiquetas, se tendría que localizar el enlace y a
partir de éste acceder al archivo RDF para interpretarlo. Una mejora imprescindible, pero que no ha
podido ser implementada durante este plazo.
55
7 BIBLIOGRAFÍA.
Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies , RFC 2045, November 1996.
Berners-Lee, T., Fielding, R. and H. Frystyk, Hypertext Transfer Protocol -- HTTP/1.0 , RFC 1945, May 1996.
Palme, J., Common Internet Message Headers , RFC 2076, February 1997. [jg640]
Berners-Lee, T., Universal Resource Identifiers in WWW , RFC 1630, June 1994.
Berners-Lee, T., Masinter, L. and M. McCahill, Uniform Resource Locators (URL) , RFC 1738, December 1994.
Ignacio Díaz Asenjo, Universidad Carlos III de Madrid, Hibernate: Persistencia de objetos en JAVA.
Enric Peig Olivé i Xavier Perramon Tornil, Universitat Oberta de Catalunya, Programació de Sockets.
José M. Barceló Ordina i Jordi Íñigo Griera, Universitat Oberta de Catalunya, TCP/IP Els protocols de la xarxa
Internet.
Ramon Martí Escalé i Xavier Perramon Tornil, Universitat Oberta de Catalunya, Aplicacions de Internet.
56
8 GLOSARIO.
URL: Un URL (Uniform Resource Locator) es el localizador que permite acceder a un recurso (página) web.
ejemplo: http : //www.direccion.com/
URI: Un URI (Uniform Resource Identifier) se diferencia de un URL en que permite acceder a una
subdirección dentro de la dirección especificada por la URL.
ejemplo: http : //www.direccion.com/ ?pagina=2 # inicio
HTML: Lenguaje de marcas utilizado como estándar en las páginas web.
XML: Metalenguaje extensible de etiquetas.
XHTML: La versión XML de HTML.
CGI: Permite solicitar datos de un programa ejecutado en un servidor web. CGI especifica el estándar para
transferir datos entre el cliente y el programa.
MIME: Son una serie de especificaciones dirigidas a que se puedan intercambiar a través de internet todo
tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario.
TCP: Protocolo orientado a la conexión, fundamentalmente utilizado para la conexión en internet.
IP: Internet Protocol. Protocolo de interconexión de red, orientado a datagrama.
COOKIE: Datos almacenados en el ordenador del visitante de una página web por el servidor de la misma.
FREEWARE: Software gratuito de uso ilimitado.
SHAREWARE: Básicamente es software gratuito con limitaciones de uso. (Como periodo de prueba).
JVM: Máquina virtual de Java.
PROTOCOLO: Normas que regulan la comunicación entre diferentes elementos de una red.
PUERTO: Interface lógica a través de la que se comunica una aplicación.
DOMINIO: Nombre con el que se conoce a una dirección IP en internet.
ICRA: Sistema de etiquetado que identifica el tipo de contenido de una web.
SOCKET: Punto final de un enlace de comunicación de dos vías, entre dos programas, normalmente a través
de la red.
DATAGRAMA: Unidad de transferencia de información en redes IP.
THREAD: Flujo secuencial de control dentro de un programa.
57

Memoria Trabajo Final de Carrera Filtrado Web

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Memoria Trabajo Final de Carrera Filtrado Web

Cargado por

Copyright:

Formatos disponibles

FILTRADO WEB CON JAVA

José Antonio Placín Holguín

A Loli, Miguel, Ana y Triky.

FILTRADO DE PÁGINAS WEB CON JAVA.

OBJETIVOS GENERALES Y ESPECÍFICOS:

PLANIFICACIÓN CON PLAZOS Y TEMPORIZACIÓN:

Primer plazo: 2 semanas (del 3 al 16 de Octubre)

Segundo plazo: 4 semanas (del 17 de Octubre al 14 de Noviembre)

Tercer plazo: 5 semanas (del 15 de Noviembre al 18 de Diciembre)

Cuarto plazo: 5 semanas (del 18 de Diciembre al 21 de Enero)

1.1 ESTUDIO DE LA SITUACIÓN ACTUAL.

FreeShield (FreeWare) Windows XP/2000/NT/ME/98

Naomi 3.2.90 (FreeWare) Windows XP/2000/NT

•Análisis heurístico que reconoce nuevos contenidos en forma automática.

•Filtro por contenidos.

Anti-Porn v9.1.3.29 (ShareWare) Windows 9x/2000/XP/Vista

•Filtrado por URL.

Internet Watcher 2000 1.9c (ShareWare) Windows 95/98/ME/NT/2000

•Filtros de publicidad, información y páginas web.

Net Nanny Home Suite (ShareWare) Windows Vista/XP/2000

•Muy fácil de usar.

Censor Net Professional (OpenSource) Debian 4.0

•Análisis léxico en tiempo real y múltiples idiomas.

1.1.2 EVALUACIÓN DE LA UTILIDAD.

1.1.3 EVALUACIÓN DEL USO.

1.2.1 PROTOCOLO HTTP.

1.2.1.3 Peticiones (Request) HTTP

1.2.1.4 Respuestas (Response) HTTP

La tabla 1.2.1.4 muestra los códigos más usuales.

1.2.1.5 Cabeceras HTTP

1.3 LENGUAJE HTML

1.3.1 ESTRUCTURA DE LOS DOCUMENTOS HTML

1.3.2 FORMULARIOS HTML

Las etiquetas básicas de los formularios HTML, son:

2.4 GLOSARIO DEL MODELO DE NEGOCIO.

1 – Puertos bien conocidos: del 0 al 1023

2 – Puertos registrados: del 1024 al 49151

3 – Puertos dinámicos o privados : del 49152 al 65535

2.5 DOCUMENTACIÓN TEXTUAL DE LOS CASOS DE USO.

-Funcionalidad: Pondrá en marcha la aplicación de filtrado.

-Funcionalidad: Dar de alta usuarios y adjudicarles permisos.

-Funcionalidad: Modificar lista de dominios prohibidos.

-Precondición: Identificarse como Administrador.

-Funcionalidad: Modificar listado de palabras prohibidas, cuya aparición en un recurso provocará su

-Funcionalidad: Comprobar si una petición detectada ha de ser denegada o no.

-Funcionalidad: Comprobar si el puerto de destino de la petición está en la lista de puertos permitidos.

-Funcionalidad: Solicitar recurso demandado en la petición, al web.

-Funcionalidad: Aplicar los filtros al recurso obtenido del web.

-Funcionalidad: Aplicar el filtro de códigos ICRA al recurso obtenido del web.

-Funcionalidad: Retransmitir al cliente el recurso que solicitó, una vez filtrado.

-Funcionalidad: Comunicar al usuario el resultado negativo a su petición, y una breve explicación.

2.6 ESPECIFICACIÓN DE LAS CLASES.

2.6.1 IDENTIFICACIÓN DE LAS CLASES DE IDENTIDAD.

•ListaICRA. También es de entidad y persistente. En el fichero “listacodigos” se almacenará la lista de

Con esto nos queda un diagrama de clases como el de la figura 2.6.1.1.

2.7 DIAGRAMAS DE COLABORACIÓN.

2.8 INTERFACE DE USUARIO.

3.1 DISEÑO DE LOS CASOS DE USO

“1” Administrar usuarios

“2” Administrar lista palabras

“3” Administrar dominios

“4” Administrar códigos ICRA

“5” Administrar puertos

“6” Administrar registro