Capítulo 3 Aplicación desarrollada
“ Aquella teoría que no encuentre aplicación práctica en la vida, es una acrobacia del pensamiento.” Swami Vivekananda. Líder espiritual y reformador hindú.
Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.1 Introducción
Este capítulo contiene las definiciones y oportunas explicaciones técnicas de la aplicación desarrollada en este proyecto. A continuación se adjunta el diagrama de la aplicación desarrollada:
Figura 2: Plataforma Ninbox
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
La aplicación desarrollada, plataforma Ninbox, puede ser dividida en 3 partes: el núcleo con el sistema de autenticación, el editor WYSIWYG y la aplicación webConference llamada Talkinbox. Como se comentó en los objetivos del proyecto, la plataforma Ninbox está diseñada para ser soporte de una aplicación e-Learning. Toda aplicación web posee una parte ejecutada en el servidor y una ejecutada en el navegador del cliente. La plataforma Ninbox actúa en las dos partes. Como se puede observar en la figura, las partes que integra la plataforma Ninbox (zonas de color verde) son principalmente el editor WYSIWYG, la aplicación webConference (Talkinbox) y el núcleo que proporciona el sistema de autenticación. Cada una de estas partes es representada en la figura con un flujo de entrada/salida ( flechas rojas ) que intenta sintetizar el principal funcionamiento.
A modo de introducción se explican a continuación los diferentes flujos de comunicación y las principales funciones de cada parte. El flujo 1, comunica el formulario de autenticación, ejecutado en cliente. Este formulario recibe usuario/contraseña y los envía al servidor (flujo 2), dónde se ejecuta el módulo de autenticación que mediante el acceso a librerías proporcionadas por el núcleo (flujo 3) establece las variables globales y las sesiones de servidor que proporcionan un sistema de single-sign-on, es decir una única autenticación y que será explicada a lo largo de este capítulo. El formulario de autenticación posee un flujo de salida hacia el cliente (flujo 1) que puede dividirse en dos: – Flujo de interfaz: donde se proporcionan mensajes de error en autenticación o autenticación satisfactoria con información de usuario. – Flujo javascript: establece cookie en cliente para recordar sesión, control de autenticación en la misma máquina...
El editor WYSIWYG, ejecutado en el cliente, proporciona el punto principal de comunicación cliente-aplicación (flujo 6 y flujo 7). Mediante esta aplicación el cliente
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada introduce información en el sistema, además del flujo de salida que proporciona el propio funcionamiento WYSIWYG, es decir las modificaciones que el usuario realice en el texto, la inserción de imágenes... se visualizan en tiempo real.
Cuando la aplicación e-Learning ( que sea integrada con la plataforma Ninbox) recibe información del cliente o realiza consultas para mostrar información utiliza el núcleo de la plataforma que proporciona API´s para la comunicación con la base de datos, las sesiones de servidor, las cookies de los clientes, control de roles y privilegios (flujo 5).
Por último, se ha desarrollado una aplicación webConference, que proporciona la posibilidad de crear aulas virtuales e impartir clases online. Dicha aplicación tiene una parte ejecutada en cliente ( editor WYSIWYG y Javascript para envío de formularios y control de interfaz: flujo 9) y una parte ejecutada en servidor (PHP para la comunicación con el núcleo para consultas mySQL y control de sesiones: flujo 8 ). La plataforma Ninbox proporciona un sistema de plantillas para la generación de documentos XHTML que puede ser utilizado por la aplicación integrada en la generación del contenido de las páginas web. Como se comentó en el capítulo 2, la arquitectura empleada en programación de la plataforma ha sido MVC (Modelo Vista Controlador), adaptada al lenguaje empleado, PHP. Esta arquitectura, como su nombre indica, está compuesta por tres componentes: Modelo: que es compuesta por todos los archivos PHP que generan el dominio de la web. Vista: compuesta por los códigos y recursos empleados en la generación de la interfaz. Controlador: conforma el punto de conexión entre el modelo y la vista; y en este proyecto está compuesto por los códigos Javascript.
A continuación se muestra una figura que ilustra como las diferentes partes de la plataforma Ninbox se dividen en las componentes de la arquitectura empleada:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 3: Arquitectura MVC de la plataforma Ninbox
A continuación se detallan las componentes de la arquitectura:
Modelo: los diferentes archivos PHP que configuran las diferentes partes del sistema, además de las bibliotecas PHP necesarias para su funcionamiento. En cada uno de los modelos del sistema se importaran los sistemas de control y de vista necesarios para
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada completar su correcta composición. Concretamente el utilizo de las plantillas será implementado mediante la librería Smarty-PHP, cuya información podemos encontrar en el punto 9.2 Referencias web. Por otra parte la incorporación del controlador por parte de los modelos se realizara mediante la librería xajax para el control mediante AJAX y por incrustación directa de los archivos Javascript para los demás controladores. La referencias a la biblioteca XAJAX se encuentran en el punto 9.2 Referencias web. Además se incluirán en esta parte los archivos de lenguaje que serán archivos PHP, según la variable de sistema lang, incorporarán un lenguaje u otro que será usado para la representación de la información. Todos estos archivos estarán situados en una carpeta llamada model, y que de aquí en adelante conforma la carpeta raíz de la plataforma Ninbox.
Vista: serán las diferentes plantillas XHTML generadas según el protocolo de la librería Smarty-PHP ,y los archivos CSS que formatearán las plantillas. Los archivos que componen esta parte está ubicados en la carpeta VIEW que se encuentra dentro de la carpeta raíz model.
Controlador: está compuesto por las bibliotecas Javascript creadas a propósito para este sistema y además se incluirá la biblioteca SCRIPT.ACULO.US cuya referencia se puede encontrar en los apéndices y que nos proporciona efectos dinámicos en la interfaz. Los archivos que componen esta parte está ubicados en la carpeta CONTROLLER que se encuentra dentro de la carpeta raíz model. El hecho de que tanto la carpeta CONTROLLER como la carpeta VIEW se encuentren dentro de la carpeta model y no en un nivel paralelo simplemente es debido a una política de simplicidad en el uso de direcciones relativas a la hora de importar o incluir bibliotecas o archivos.
Este capítulo está dividido en 5 grandes partes. La primera de ellas dedicada a la componente modelo, la segunda al vista y la tercera al controlador, la cuarta a las otras aplicaciones (editor WYSIWYG y webConference) y acabando con una última parte dedicada a las conclusiones de este capítulo.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Dentro de cada una de estas partes se explican los diferentes componentes de la aplicación que componen la plataforma. Esta división se ha realizado siguiendo la línea de lógica de este proyecto, es decir, la división de parte de programación servidor, interfaz y programación cliente, como se verá en los siguientes puntos. Como puede observarse el editor WYSIWYG posee una componente vista y una componente modelo, de la misma manera la aplicación webConference tiene una parte de cada componente.
No obstante, por simplicidad y claridad se ha decidido documentar al completo estas dos aplicaciones en una sección independiente llamada Otras aplicaciones integradas.
El núcleo del sistema está dividido en las diferentes secciones correspondiente a las componentes de la arquitectura.
Para aclarar referencias en carpetas que se realizan a lo largo del capítulo se adjunta resumen de la arquitectura de directorios de la aplicación:
model (carpeta raíz): contiene los archivos que componen la componente modelo VIEW (subcarpeta de model): archivos que componen la componente vista CONTROLLER(subcarpeta de model): archivos que componen la componente controlador.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.2 Componente modelo
3.2.1 Introducción
La componente modelo está principalmente compuesto por los diferentes archivos PHP que configuran las diferentes partes del sistema, además de las bibliotecas PHP necesarias para su funcionamiento. En cada uno de los modelos del sistema se importaran los sistemas de control y de vista necesarios para completar su correcta composición. Sintetizando, principalmente se incluyen este punto todos los archivos con código de programación de servidor que componen el sistema. Es decir, toda la lógica de control del núcleo que se encarga de proporcionar las API's de comunicación con el servidor, la base de datos..., control de autenticación. A modo orientativo, en este punto 3.2 Componente modelo, se comienza explicando el núcleo del sistema y su integración y posteriormente se explica como se ha insertado la capacidad de comunicación mediante AJAX. Cabe destacar que no están incluidos ninguno de las partes del núcleo relacionadas con la interfaz gráfica que se genera ( componente vista ) ni con los archivos Javascript que permitan funciones de interacción del cliente con el sistema ( componente controlador ).
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.2.2 Núcleo
El núcleo del sistema es principalmente una base de código PHP que define API's de comunicación, mecanismo de depuración y ante todo mecanismos de autenticación y control de acceso. Está diseñado especialmente para integrarlo en sistema e-Learning por el cálculo de privilegios de control que realiza, y que se presenta como una buena solución para gestionar los diferentes recursos en relación a los diferentes roles de los usuarios.
3.2.2.1 Introducción
El núcleo del sistema Ninbox está compuesto por varios archivos PHP que contienen las clases necesarias para su ejecución. Todos estos archivos están incluidos en la carpeta phpCore que se encuentra en la raíz de la carpeta model. El núcleo tiene como función principal la inicialización de todas las API's y clases necesarias para el manejo de contenidos web. Además contiene clases para el control y manejo de errores y excepciones, de usuarios, de internacionalización del documento. De modo resumido el núcleo es ejecutado al inicio de cada página, de esta manera a partir de su ejecución tenemos accesibles todos los métodos y funciones necesarias para desde controlar las cookies del usuario hasta generar documentos XHTML mediante plantillas. A lo largo de este punto se analiza paso a paso la estructura del documento web donde es insertado hasta cada una de las Clases y API's que lo componen; así como su funciones y sus características.
3.2.2.2 Estructura básica de la web
Antes de comenzar a describir todos los puntos del núcleo se va realizar una descripción del marco en el que se encuentra insertado; es decir la estructura común de cada página del sistema.
La estructura básica de una web de estas características suele ser de este tipo:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 4: Estructura básica de páginas dinámicas
Es decir, comúnmente, se suele primero importar archivos PHP necesarios en el procesamiento y luego procesar los datos más relevantes. A continuación se suele abrir el flujo HTML, es decir, a partir de aquí la información que se envía al navegador, incluyendo cabeceras HTTP. A lo largo de la generación del código HTML se insertan líneas de código PHP, ya sea para procesar o tan sólo para imprimir valores de variables. Esta forma de componer el archivo no es tan sólo poco estructurada, dado que se está mezclando en un mismo archivo físico diferentes códigos ( Javascript,PHP...), si no que además se mezclan con el lenguaje de etiquetado HTML e incluso con CSS. Si ocurriese un error a lo largo de la creación de código no habría manera de redireccionar el navegador puesto que ya se ha enviado la cabecera HTTP, por el mismo motivo, no se podría insertar cookies; y además aunque se lanzase una excepción para paralizar la ejecución algo de contenido HTML ya habría llegado al usuario.
Pero evidentemente lo más negativo de esta forma de programar es la modularidad. Se debe siempre intentar separar los diferentes lenguajes y además separar de tal manera que posibles actualizaciones de código no afecten a las diferentes partes. En este caso si decidiésemos cambiar la interfaz del sistema deberíamos cambiar todos los archivos PHP y además cambiar el código insertado entre sus líneas; si en cambio se desea
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada migrar a otro tipo de base de datos se deberían una vez más cambiar todos los archivos.
La estructura de los archivos del sistema ninbox en cambio se puede sintetizar con el siguiente esquema:
Figura 5: Estructura básica de las páginas de Ninbox
Como se puede observar cada archivo PHP del modelo, solo contiene código PHP. Se comienza importando todos los archivos necesarios para el procesamiento y a continuación se instancia la clase Ninbox, que es la principal clase del núcleo puesto que en su ejecución se crean todas las demás clases. Después de realizar el procesamiento común de toda página del sistema , que se identifica con la ejecución del núcleo, se pasa a la ejecución propia de cada página. Es decir, si se encuentra en la página que muestra los usuarios online, en esta parte se realizaría una consulta de dichos miembros y posteriormente se crearía el array que contiene toda esta información.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Por último se utiliza la librería Smarty-PHP que se encuentra bajo licencia GNU para la generación de código XHTML. Smarty-PHP es un motor de plantillas y su función es tomar el array de datos e inyectar dicha información en los archivos TPL ( plantillas XHTML) y mandar el resultado al navegador. De esta manera todos los códigos y lenguajes están separados y nunca se envía la cabecera HTTP antes de comprobar el correcto procesamiento PHP. Como se podrá ver más adelante esta estructura es algo más compleja puesto que existen más código y partes que no están incluidas en este esquema.
En el siguiente capítulo se verá con detalle la clase Ninbox y se describirá su funcionalidad y justificará su importancia.
3.2.2.3 La clase Ninbox
La clase Ninbox como se ha comentado anteriormente es la clase principal del núcleo, se encuentra en la subcarpeta phpCore de la carpeta raíz model. Se puede ver como la clase contenedora de todas las demás clases del sistema, es decir la interfaz de todo el procesamiento PHP. Antes de explicar su funcionalidad se mostrará un esquema de su estructura:
Posee una amplia colección de variables de instancia, algunas sirven para almacenamiento de valores relevantes de la configuración del sistema, como por ejemplo contraseña de la base de datos, lenguaje del sistema...
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 6: Estructura básica de la clase Ninbox
Otras variables sirven para almacenar contenidos temporales de cada página, como puede ser el campo TITLE , o los campos META de keyword para los robots de los buscadores. Pero el mayor número de variables se utiliza como referencia a objetos de las clases y API's del sistema. De este modo, y como se verá con más detalle en los siguientes apartados, si por ejemplo, hablamos de la API de COOKIES, en la función Init de Ninbox (constructor de las clases en el lenguaje PHP), se crea un objeto:
$this->cookie=new COOKIES();
Siendo COOKIES el nombre de la clase y $this->cookie la forma de referirnos a la variable de instancia cookie. De esta manera en procesamientos posteriores a la inicialización del núcleo, cuando se
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada desee utilizar la API de COOKIES, se podrá realizar de la siguiente manera:
$ninbox->cookie->getData('myCookie','id');
En este ejemplo se está leyendo la cookie llamada myCookie y concretamente se está extrayendo la variable Id de dicha cookie. Teniendo en cuenta el esquema de la estructura de dicha clase, a continuación de las variables de instancia , se encuentran los métodos. Cabe destacar las funciones del método Init que se encarga de instanciar todas las clases que se enumeran a continuación y que posteriormente se describirán:
CONFIG, SESSIONS, DEBUGGER, GMT, ExHandler, DataBase, COOKIES, CONTROL, AUTH, I18N, basicTemplates y xajax
El método checkRegister se verá con más detenimiento en el apartado 3.2.2.6 Control de usuarios y seguridad en acceso. El método getPrivileges está descrito completamente en el apartado 3.2.2.7 Grupos y privilegios. Todas las clases y por tanto la funcionalidad al completo se irán describiendo en los apartados siguientes.
3.2.2.4 API's del núcleo
3.2.2.4.1 Introducción
En es te apartado se describen todas las API's iniciadas por la clase Ninbox y que conforman el núcleo del sistema. Se irán describiendo en orden de ejecución en la inicialización del núcleo y se describirá sus funciones de modo general, las mejoras que se obtienen en su uso y los aspectos técnicos más significativos.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.2.2.4.2 SESSIONS
Esta clase está definida en el archivo sessions.php de la subcarpeta phpCore de la carpeta model. En el constructor se realiza la creación de la sesión del servidor y su principal función es crear una interfaz con las variables de session del servidor. Incluye los siguientes métodos:
➢ setId($id) : Establece el identificador de sesión ➢ getId() : Recupera el identificador de sesión ➢ getDataArray() : Recupera el array de variables de sesión ➢ getData($variable) : Recupera una variable de sesión ➢ setDataArray($data) : Establece el array de variables de sesión ➢ setData($variable,$value) : Establece una variable de sesión con valor ➢ delete($variable) : Borra una variable de sesión ➢ deleteAll() : Borra el array completo de variables de sesión ➢ destroy() : Elimina la sesión en el servidor
La principal ventaja que aporta esta API es proporcionar unos métodos concretos que evitan el manejo del array completo de variables de sesión. Además en caso de migración de lenguaje el código cambiaría pero no la estructura del sistema.
Otra ventaja puede observarse en el caso en el que el sistema esté instalado en un servidor con sesiones desactivadas, en este caso la API proporciona una salida correcta y no se lanzaría ningún error, además podría ser modificado el comportamiento de sus salidas para que todo el sistema no se vea afectado.
3.2.2.4.3 DataBase
Esta clase está contenida en el archivo database.php de la subcarpeta phpCore de la carpeta raíz model.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Su principal función es crear una interfaz con el sistema de base de datos, concretamente en este caso se ha optado por MySQL. En el constructor se realiza la conexión con el servidor MySQL mediante los datos de configuración que proporciona la clase CONFIG que se verá en el punto 3.2.3 Integración del núcleo en el sistema.
La clase database proporciona los siguientes métodos:
➢ send($sql,$type='ARRAY'): Envía una consulta al servidor ➢ select($table,$where,$type='ARRAY'): Realiza una consulta SELECT al servidor con el discriminador $where y devuelve un array de tipo $type (indexado, asociativo o mixto) o false en caso de error o no existencia de resultados. ➢ insert($table,$data): Realiza una consulta INSERT al servidor tomando como datos $data ( array ) y devuelve false en caso de error. ➢ update($table, $update, $where,$SQLInyection='YES'): Realiza una consulta UPDATE al servidor tomando como datos $update ( array ) en los campos según discriminador $where, con opción a control de inyección SQL según el valor de la variable $SQLInyection; devuelve false en caso de error. ➢ delete($table,$where): Realiza una consulta DELETE al servidor según el discriminador $where; devuelve false en caso de error. ➢ secure($valor): Método que recibe una consulta y escapa todos aquellos caracteres que puedan vulnerar la seguridad del sistema, evitando la inyección de código SQL. Devuelve la consulta en modo seguro. ➢ close(): Cierra la conexión ➢ stats($new='yes'): Realiza un seguimiento y actualización de todos los parámetros del sistema, almacenando dichos valores por días.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Utiliza la tabla stat_system, para más detalles capítulo 7.6 Planos de base de datos
Esta API puede considerarse una de las más importantes del sistema, puesto que tiene la función de mantener una correcta comunicación Ninbox Core - MySQL Server. El método secure proporciona un buen mecanismo para asegurar que los datos insertados por los usuarios nunca produzcan efectos no deseados. Además proporciona una colección de métodos que generan una capa superior para su manejo. Cada uno de estos métodos realiza la consulta, lanza excepción en caso de error y devuelve los resultados. Para ver con más detenimiento el manejo de excepciones ver apartado 3.2.2.5.2 ExHandler.
Por último cabe destacar que en caso migración de sistema de base de datos , sólo habría que modificar esta API, puesto que siempre se utilizan sus métodos para realizar cualquier consulta en el sistema.
3.2.2.4.4 COOKIES
Esta clase está definida en el archivo cookies.php de la subcarpeta phpCore de la carpeta raíz model. Su principal función es crear una interfaz para el manejo de las cookies del cliente.
Incluye los siguientes métodos:
➢ create($name,$data,$expire=3600): Crea una cookie, en el cliente con nombre $name,con valores de variable dados por el array $data y con fecha de expiración $expire. Este método debe ser siempre utilizado antes de enviar las cabeceras HTTP. ➢ read($name): Devuelve un array con las variables de la cookie $name, en caso de error devuelve false.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
➢ getData($name,$variable): Devuelve el valor de la variable $variable que se encuentra en la cookie de cliente $name, ➢ setData($name,$variable,$value,$expire=3600): Establece el valor de una variable $variable en una cookie de cliente $name con valor $value y con fecha de caducidad $expire, en caso de no existir crea la entrada. Si ocurre un error devuelve false. ➢ delete($name): Elimina la cookie de cliente $name.
Esta API proporciona una interfaz cómoda para el manejo de las variables de cookies, ahorrando código y gestionando posibles fallos o errores de manera transparente al programador.
3.2.2.5 Clases de control de errores
3.2.2.5.1 Introducción
En este apartado se explicarán las clases que componen al núcleo del sistema cuya función es el control y manejo de errores y/o excepciones y su análisis. Estas clases son instanciadas en la clase Ninbox y son ExHandler y DEBUGGER. A continuación se explicará su uso y características.
3.2.2.5.2 ExHandler
La clase ExHandler está definida en el archivo exhandler.php de la subcarpeta phpCore. Su función principal es definir los manejadores de errores y excepciones y las propias funciones manejadoras. Es instanciada en el método Init de la clase Ninbox.
En su constructor se realizan las siguientes operaciones:
$GLOBALS['error_stack']=array(); @set_exception_handler(array('ExHandler', 'exception_handler')); @set_error_handler(array('ExHandler', 'error_handler'));
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
La primera de las operaciones es definir la pila de errores en la variable global error_stack. La segunda de las operaciones es definir como manejador de excepciones al método estático exception_handler definido en esta misma clase y que se detalla posteriormente. La tercera de las operaciones es definir como manejador de errores al método estático error_handler definido en esta misma clase posteriormente.
Los métodos definidos en esta clase son los métodos estáticos mencionados anteriormente.El método:
public static function error_handler($num_err, $cadena_err, $archivo_err, $linea_err)
Este método recoge como parámetros el código de error, la cadena de error, el archivo en el que ocurrió el error y la línea. Estos parámetros deben ser fijos y están definidos en la documentación de PHP. Este método será llamado automáticamente cada vez que ocurra un error o cada vez que exista un NOTICE (warnings) si el modo debug está activo, para más información sobre el modo debug véase el punto 3.2.2.5.3 DEBUGGER. Además puede ser invocado manualmente con la función trigger_error, si se desea registrar errores de tipo navegación ( errores cometidos en la lógica de flujo de la aplicación, como puede ser intentar acceder a zona restringida). Este método registra estos datos en la pila de errores , pero no imprime nada por pantalla, evitando facilitar información a posibles atacantes.
El método:
public static function exception_handler($exception)
es invocado cada vez que se lanza una excepción del siguiente modo:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
throw new Exception("descripción de excepción");
Estas excepciones se lanzan en caso de errores graves, como por ejemplo en la clase database, cuando se envía una consulta a una tabla y esta tabla no existe.
La descripción de la excepción lleva el siguiente sintaxis:
código de error ( 4 dígitos ) : Descripción del error [ : sentencia que produjo el error ]
Existen 3 tipos de códigos de error identificado por el primer dígito:
➢ 0xxx : Errores graves ➢ 1xxx : Errores importantes ➢ 2xxx : Errores de navegación
Dependiendo del tipo de error el método actuará de una manera. En caso de que el error sea de tipo 0xxx, la ejecución de la aplicación se interrumpe y se muestra un mensaje de advertencia; en caso de que el sistema detecte que el usuario es el SUPERUSUARIO muestra un trazado de error y un acceso para ponerse en contacto con el departamento de soporte de Ninbox ( en caso de que exista una hipotética plataforma Ninbox).
Figura 7: Interrupción de ejecución y trazado de errores para administrador
Estos tipos de errores son aquellos que se han producido por un fallo grave en el sistema y no se puede continuar la ejecución , además se realiza un registro de dicho error
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada en el archivo errors.log que se encuentra en la subcarpeta logs.
En caso de que el error sea de tipo 1xxx, se redirecciona el navegador a la página error.php que se encuentra en el dominio del sistema (carpeta raíz model). Esta página muestra la descripción del error y su posibles soluciones. En este caso también se registra el error en el archivo errors.log. Esto errores son normalmente producidos por situaciones anómalas en la ejecución del script, pero no son errores de programación o posibles bugs de códigos. No obstante son importantes y por este motivo se registran. Un ejemplo de este tipo de error es el lanzado cuando un usuario intenta acceder a una zona restringida para SUPERUSUARIO.
En caso de que el error sea de tipo 2xxx se actúa de igual manera que el anterior, pero no se registra el error en el archivo. Estos errores son producidos por la navegación del usuario, por ejemplo introducir mal la password. Todos los errores que son registrado en el archivo errors.log son insertado junto a la fecha y hora en la que se produjo según el meridiano de Greenwitch. Para conocer todos los diferentes errores registrados véase el punto 7.7 Tabla de errores.
3.2.2.5.3 DEBUGGER
La clase DEBUGGER está definida en el archivo debugger.php de la subcarpeta phpCore. Su función principal es la de proporcionar un trazado completo de variables de sistema y de pila de errores al administrador. Es decir, está función solo muestra salida si el administrador ha activado la variable de sesión debug, dicha activación se realiza por medio de un acceso directo que es generado en la interfaz si detecta el propio sistema que el usuario que navega tiene los privilegios adecuados. Para más información sobre privilegios ver apartado 3.2.2.7 Grupos y privilegios.
Esta clase es instanciada en el método Init de la clase Ninbox. En su constructor se detecta si la variable de sesión debug está activada y en tal caso realiza las siguientes
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada operaciones
error_reporting(E_ALL & ~E_NOTICE); $GLOBALS['system']['micro']=microtime();
Con la primera operación se indica al servidor PHP que genere la salida de todos los warnings y errores. Por defecto, los servidores están configurados para mostrar solo los errores graves dado que pequeños warning o notices no se deben mostrar para evitar filtración de información a posibles atacantes. De esta manera cuanto está activo este modo , se registrará en la pila de errores cualquier notice o warning; para más información sobre la pila de errores véase punto 3.2.2.5.2 ExHandler.
La segunda de las operaciones es grabar en una variable global del sistema el valor en microsegundos que se recoge antes de comenzar la ejecución del script. El unico método que incluye esta clase es make que es llamado en el método close de la clase Ninbox. Este método de la clase Ninbox es llamado al final de todas las páginas y como se explico anteriormente cierra todos los flujos. Este método make de la clase DEBUGGER comprueba si la variable de sesión debug está activa y en caso afirmativo genera una interfaz de administración que se muestra a continuación del contenido de la página en la que se encuentre el administrador. Esta interfaz muestra información relevante para el programador como es:
➢ Nombre del script ejecutado y parámetros de entrada ➢ Tiempo de ejecución del script ➢ Volcado de variables de sesión ➢ Volcado de variables de cookies ➢ Volcado de la pila de errores
Además esta clase puede ejecutarse en dos modos: Screen mode o Log Mode. En el modo Screen todo el volcado de pila se hace por pantalla; en el modo Log además se
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada realiza un registro en el archivos errors.log que se encuentra en la subcarpeta log; para más información véase punto 3.2.2.5.2 ExHandler.
A continuación se muestra un ejemplo de la interfaz de administración que genera esta clase cuando esta activada la variable de sesión debug.
Figura 8: Captura del trazado en modo debug on
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.2.2.6 Control de usuarios y seguridad en acceso
3.2.2.6.1 Introducción
En este apartado se describen todos los procesos que el sistema efectúa para el control de usuarios; el registro, la activación de cuentas y la detección de privilegios, además de otros métodos para seguridad avanzada que posee. Las clases más importantes que realizan estas operaciones son CONTROL, AUTH y el método checkRegister de la clase Ninbox. A lo largo de los siguientes apartados se irá describiendo cada una de estas partes.
3.2.2.6.2 CONTROL
La clase CONTROL está definida en el archivo control.php de la subcarpeta phpCore. Esta clase también forma parte del denominado núcleo del sistema.
Su principal función es controlar los accesos, creando las sesiones y su identificador único, guardar la información en sesión y en cookies; mantener actualizada la lista de usuarios online y algunas funciones más sobre seguridad que se detalla posteriormente.
Esta clase es instanciada en la clase contenedor Ninbox, concretamente en su método Init . El constructor de la clase CONTROL realiza las siguientes operaciones: ➢ Comprueba si se ha enviado el formulario de registro ( donde se inserta login y password del usuario para iniciar sesión). ➢ Se detectan las variables POST login y pass (petición de inicio de sesión ) y en caso afirmativo se realiza una llamada al método registerUser que se verá
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
posteriormente. ➢ Se realiza una llamada al método checkBrowser que a su vez realiza una llamada al método getBrowser, este último método obtiene mediante la variable de servidor $_SERVER['HTTP_USER_AGENT'] ( que contiene información de las cabeceras HTTP) el tipo de navegador que utiliza el visitante; finalmente checkBrowser almacena en la variable de sesión browser el tipo del navegador. Esta operación se realiza para identificar en cada momento el navegador del visitante y adecuar el contenido a su correcta interpretación. ➢ Se realiza una llamada al método checkCookies, este método comprueba que el usuario tiene la cookie con nombre idsession almacenada y la variable de sesión login a 0, o simplemente no tiene creada aún la variable de sesión login. En cualquiera de los casos anteriores se comprueba la cookie autoregister del usuario y en caso afirmativo se extraen los valores de dicha cookie que son el login y un identificador de registro único para cotejarlo con la información almacenada en base de datos del usuario y en caso positivo realizar la llamada a registerUser, que se verá más adelante ( inicio de sesión automático).
Resumiendo, si el usuario no tiene la cookie idsesión es porque el usuario está entrando en ese preciso instante en el sistema o porque tiene desactivadas las cookies, por este motivo además se comprueba que la variable de sesión login esté a 0, eso quiere decir que el usuario ha entrado pero no se ha registrado. La otra comprobación de que no tenga la variable de sesión activada quiere decir que es la primera vez que entra en el sistema. Si ocurre cualquiera de estas premisas el sistema comprueba la cookie que se almacena en el ordenador del usuario cuando se registra y activa la casilla Recordar sesión.
Esta cookie contiene las variables login y pass, que no es el verdadero password del usuario, sino un identificador único que se crea cada vez que el usuario se registra y se almacena en la tabla members, para más información sobre esta base de datos ver 7.6 Planos de base de datos. Se cotejan los datos de la cookie con los de la base de datos y en caso satisfactorio se realiza la llamada al método registerUser que establece al usuario
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada actual como miembro del sistema.
Figura 9: Formulario de inicio de sesión del sistema
Por ultimo, en el constructor de CONTROL se realiza la llamada al método analyze, en este método se llevan a cabo todas las comprobaciones de control de acceso. Hay que remarcar que todos estos métodos son llamados siempre al inicio de cada página. Lo primero que se realiza es la comprobación de que la variable de sesión idsession esté registrada, en caso negativo querrá decir que el usuario acaba de entrar en el sistema. Si es así, se realiza una llamada al método getRealIP que obtiene la IP real del visitante, detectando si ha utilizado servidores proxies en su conexión. Después realiza una comprobación para detectar si la IP está banneada (expulsada), toda la documentación sobre monitorización se encuentra en el punto 3.2.2.6.5 Monitorización. A continuación se registran todas las variables de sesión a los valores por defecto del sistema. Las variables de sesión son: ➢ browser: Fue establecida en el método getBrowser. ➢ Idsession: Es establecida en este método. ➢ Ip: Es establecida en este método. ➢ bot: Es establecida en este método, su valor inicial es de 0, sirve para almacenar cuantas operaciones del robot del sistema ha realizado el actual usuario. De esta manera se consigue un uso ponderado de ciclos de reloj por cada usuario para realizar tareas de dicho robot, como por ejemplo, el mantenimiento de las DDBB o
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
el autoborrado de SPAM. ➢ login: Es establecida en este método, su valor inicial es 0, indicando que no es miembro del sistema, cuando se registra el usuario contendrá el valor del login, es modificada en el método registerUser. ➢ iduser: Es establecida es este método, su valor inicial es -1. Al igual que en la variable anterior su valor es modificado en registerUser, conteniendo el valor del identificador de usuario que exista en la tabla members. ➢ gmt : Es establecida en este método. Su valor por defecto se toma de la variable de configuración de sistema GMT, indicando que zona horaria se desea utilizar para mostrar todas las fechas. ➢ data_format : Es establecido en este método y su valor se toma de configuración. Indica en que formato se desea ver las fechas, mes/día/año o bien día/mes/año. ➢ detect_summer: Es establecida en este método. Indica si el usuario o sistema desean ajustar el horario al cambio de verano (+1) si es oportuno. ➢ language:Al igual que las variables anteriores es establecida en este método, y como las anteriores se toma el valor de la variable de configuración de sistema language. Indicando qué diccionario se debe cargar para generar la interfaz. ➢ Oldzone: Es establecida en este método y almacena la zona de sistema en la que se encontró el usuario en el paso anterior. ➢ Zone: Es establecida en este método y almacena la zona del sistema en la que se encontra el usuario en ese instante. ➢ Debug: Es establecida en la clase DEBUGGER.
Finalmente se realiza una llamada al método refresh que actualiza la tabla users_control. En esta tabla se almacena las sesiones de la plataforma que existen iniciadas en el servidor. Se almacena además información relevante por cada sesión como es login, zone, time. Esta última variable, time, nos indica el último acceso a sistema de cada sesión. En caso de que este tiempo sea superior al valor definido por la variable de sistema ghost_time, por defecto 5 minutos, se borra la entrada. De esta manera, cada vez que un usuario carga una página actualiza su información de sesión y borra las entradas “caducadas”, manteniendo control sobre los usuarios que se
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada encuentran online.
En la clase CONTROL nos encontramos también con los siguientes métodos:
➢ registerUser: este método realiza una consulta a la tabla members para comprobar que se cumple la igualdad entre la pareja password/curret_is y login. Si es así actualiza las variables de sesión a los valores que tenga el usuario elegidos. Por ejemplo si el sistema está en Español, pero el usuario tiene escogido Italiano, en estos momentos se actualiza la variable de sesión language a it y se cargará el diccionario de Italiano , generando así la interfaz adecuada. Destacar que antes de realizar esta activación se comprueba que la cuenta está activa y se realiza tareas de monitorización sobre login. Ademas si se activó la casilla Recordad Sesion, se envía la cookies autoregister al usuario con los valores adecuados.
➢ unregisterUser: realiza la operación inversa, establece todos los valores de sesión por defecto.
Resumiendo, la clase control inicia todas las variables de sesión, controla los valores de las cookies, mantiene la tabla de usuarios online, realiza los registros de usuarios , actualiza la estadística de sistema y realiza las operaciones de monitorización que se describe más adelante.
3.2.2.6.3 AUTH
La clase AUTH está definida en el archivo control.php de la subcarpeta phpCore. Esta clase también forma parte del núcleo del sistema. Es instanciada en el método Init de la clase Ninbox. Su constructor recibe como parámetro una variable que se utiliza como discriminador para generar un control de acceso. Esta clase es utilizada para redundar la seguridad en zonas de administración general y en
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada zonas que se agreguen al sistema y que no sigan el mapa de privilegios que se puede ver en el punto 3.2.2.7 Grupos y privilegios. La variable que se le pasa a este constructor es la constante P_AUTH que debe estar definida en todos los archivos del sistema: define("P_AUTH",""); Los posibles valores de esta constante son: ➢ cadena vacía, NULL o PUBLIC: en tal caso esta clase no realiza ninguna operación. ➢ REG: comprueba que el usuario esté registrado, en caso negativo lanza el error 2100 y se redirecciona a la página de error. ➢ ROOT: en este caso se comprueba que el usuario que está visitando la página sea el SUPERUSUARIO, es decir tiene el campo root de la tabla member activo. Se lanza un registro de usuario mediante la cabecera HTTP y se comprueba que los valores de autenticación son los correctos, en caso fallido se lanza el error 1101 que redirecciona a la pagina de error error.php y además registra el error en errors.log grabando la IP de la máquina. El lanzamiento de registro por HTTP se ha incluido para evitar ataques mediante referal o error en cookies, de esta manera las zonas más sensibles son protegidas de una manera más eficiente.
Esta clase proporciona un mecanismo auxiliar de seguridad que permite al administrador agregar tantas webs como quiera al sistema y tener control de acceso sobre ellas.
3.2.2.6.4 checkRegister
El método checkRegister pertenece a la clase Ninbox. Este método es llamado desde todas las páginas una vez ha finalizado todo el proceso del núcleo y además justo antes de comenzar el estudio de privilegios y el proceso de la página. Es un método que proporciona una seguridad extra en el acceso, puesto que comprueba finalmente que todas las variables de sesión tienen los valores correctos antes de comenzar el proceso. Si no es así, establece al usuario como visitante y fija todos los valores de
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada variables a sus valores por defecto. Además en caso de que el usuario esté registrado comprueba que el campo current_id de la tabla members, que es generado cada vez que el usuario se registra concuerda con la variable de sesión current_id, de esta manera se cerciora que está sesión ha sido generada por el sistema de manera adecuada y no se ha intentado realizar un ataque desde el mismo servidor, creando una sesión ilegal y ajustando los valores de las variables de sesión para emular un usuario. La variable current_id es generada en el registro del usuario y consiste en una clave unica de 128 bits creada a partir de una cifra única con semilla aleatoria codificada en md5: $current_id=md5(uniqid(rand(), true));
3.2.2.6.5 Monitorización
El sistema posee diferentes mecanismo para la monitorización de accesos. Una de las tablas que se utilizan es security. Esta tabla posee un campo llamado type en el cual se especifica el tipo de descriminador que se utiliza para el control de acceso, el segundo campo es value, y se utiliza para almacenar el valor del descriminador. El descriminador puede tomar los siguientes valores: ➢ ip: y value es la ip a la que no se desea dar servicio ➢ login: y value es el login al cual no se desea permitir registrarse ➢ mail: y value es el mail que no se permite insertar en el registro de usuarios.
En la clase CONTROL cuando se detecta la IP del navegante , se comprueba que dicha IP no esté presente en esta tabla, en caso afirmativo se lanza un error de tipo 0200. De igual manera cuando se registra un usuario se comprueba que el login en cuestión no se encuentre registrado en esta tabla. Y exactamente lo mismo para el mail.
Además existe la tabla ipaddress que registra las diferentes IPs que han utilizado los diferentes logins, en caso de que la misma IP pública haya sido utilizada por diferentes logins, se envía un mensaje automático al sistema, y se recoge en la tabla monitor_tagboard.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Dicha tabla tiene como misión recoger todos los mensajes de monitorización del sistema, para después ser mostrados al administrador. Aunque se permite compartir IP, el sistema realiza esta monitorización para tener registro de posibles futuros incidentes. La tabla monitor_tagboard posee los siguientes campos: ➢ type: tipo de mensaje, system, robot... ➢ title: IP shared, Computer shared, Monitoring .... ➢ message: contenido del mensaje ➢ time: hora del mensaje
Por ejemplo en el caso en el que el usuario carlos y el usuario tony compartan la IP 127.0.0.1 el sistema mandaría el siguiente mensaje al tagboard (cuando uno de los dos se registre y se comprueba dicha incidencia) :
type: System title: IP shared message: IP shared: 127.0.0.1 [carlos,tony]
El sistema realiza otra comprobación gracias al sistema de cookies. Cada vez que un usuario se registra en una máquina, se crea una cookie llamada members que contiene el listado de usuarios que se han registrado en esa misma máquina. El sistema lee dicha cookie, concretamente en la clase CONTROL y método registerUser , y si existen varios usuarios que se hayan registrado en la misma máquina y no se haya notificado aún, se envía el siguiente mensaje: type: System title: Computer shared message: Computer shared by [carlos,tony]
Por último, existe la posibilidad de crear monitorización personalizada. Para ello se utiliza la tabla monitor que contiene los siguientes campos: ➢ type: tipo de monitorización: login o IP ➢ target: valor del campo login o IP ➢ comment: descripción de la monitorización ➢ time: instante en la que se inicia la monitorización
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
En caso de exista, por ejemplo, la siguiente entrada en la tabla monitor : type: login target: tony ...
En el método analyze de la clase CONTROL se envía un mensaje de monitorización a la tabla monitor_tagboard por cada movimiento que realice dicho usuario. Todas estas herramientas proporcionan una gran ayuda a la hora de administrar y analizar posibles incidencias. En todos los casos de monitorización o incidencias, el sistema graba la dirección IP de la máquina que la produjo, de esta manera si se insertasen comentarios racistas, xenófobos o de cualquier otro tipo que atente contra los derechos de otros usuarios o contra la integridad del sistema o servidor se podrían justificar acciones legales.
Para más información sobre las tablas mencionadas véase el punto 7.6 Planos de base de datos.
3.2.2.7 Grupos y privilegios
3.2.2.7.1 Introducción
En este aparto se desarrolla el sistema de privilegios que Ninbox utiliza para controlar el acceso a los diferentes recursos del sistema.
Como se introdujo al inicio, y se verá de modo más detallado posteriormente, la estructura que se sigue es la de un sistema de foros. Es decir, los recursos del sistema se pueden organizar según la siguiente lista de objetos: ➢ Sistema: Este objeto hace referencia a las propiedades globales del sistema, como por ejemplo son el glosario, los perfiles avanzados ... ➢ Foro: Este objeto hace las funciones de contenedor. Es decir su función es similar a
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
la de un directorio. Pueden existir foros dentro de un foro y así sucesivamente. Sirve para clasificar los contenido y controlar su acceso. ➢ Hilo: Este objeto hace referencia a la unidad final de información del sistema. Los hilos siempre están dentro de los foros. Como se verá más adelante existen diferentes tipos de hilos, pero el caso más sencillo, sería el típico hilo de un foro que un usuario abre para realizar una consulta y donde los demás usuarios responden. ➢ Calendario: Este objeto, como su nombre indica es un calendario que poseen todos los miembros del sistema e incluso el sistema en sí ( programación de tareas automáticas, eventos...).
Todos estos objetos componen la estructura básica del sistema y sobre éstos se aplican los privilegios. Cada objeto tiene unos privilegios propios, que permiten al sistema generar interfaces de administración o de visualización al usuario. Otro concepto que se debe tener en cuenta es el de Grupo. Los privilegios que se aplican a los objetos mencionados anteriormente los poseen los grupos. Es decir, un grupo puede tener unos privilegios sobre el foro 1 y otros privilegios sobre el foro2, de tal manera que puede tener permisos de administración o de visualización para los diferentes elementos. Todo usuario, ya sea miembro registrado o visitante debe obligatoriamente pertenecer a un grupo. Para tal función existen unos grupos predefinidos en el sistema. Cuando un usuario se encuentra navegando, el sistema detecta a que grupo o grupos pertenece y de esta manera extrae los privilegios que tiene sobre los objetos. En los posteriores capítulos se detallará cuales son los privilegios de los objetos, cuales son los grupos y cual es el método para resolucionar qué permisos se tiene sobre cada objeto.
3.2.2.7.2 Grupos del sistema
Como se ha descrito anteriormente el sistema posee unos grupos por defecto que no pueden ser borrados, y son los siguientes:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
➢ SUPERUSER : grupo de super-usuario ➢ SUPERADMIN : grupo de super-administradores ➢ ADMIN : grupo de administradores ➢ SUPERMOD : grupo de super-moderadores ➢ MOD : grupo de moderadores ➢ REGISTERED : grupo de miembros ➢ AWAITING : grupo de miembros que no tiene activada aún la cuenta ➢ BANNED : grupo de miembros con acceso denegado en la tabla security ➢ NOTREGISTERED : grupo de visitantes
Todos estos grupos y los demás grupos que se creen están registrados en la tabla groups que contiene los siguientes campos:
➢ name: nombre del grupo ➢ comment: descripción del grupo ➢ type: tipo de grupo, grupo normal o matrícula ➢ limit: número máximo de miembros ➢ owner: creador del grupo ➢ time: fecha de creación
Además de estos atributos existen otros que definen cuales son los privilegios por defecto del grupo sobre los objetos:
admin_soft, admin_hard, admin_full, create_forum, create_calendar, create_profile, ninbox_search, view_profiles, view_glosay, visible, hard_mod, soft_mod, view_threads, view_notices, create_threads, create_posts, edit_own_threads, edit_own_posts, rate_threads, direct_threads, direct_posts, bbcode, images, multimedia, upload, html, search, view_attachments
De esta manera cada grupo tiene una información relacionada con su descripción y unos campos relacionados con todos los permisos que se pueden tener sobre
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada todos los objetos por defecto. Como se explica posteriormente, estos campos de privilegios por defecto se utilizarán en el caso en el que un objeto no tenga una entrada de privilegios concreta para un grupo.
Por ejemplo el grupo SUPERUSER, tiene como número máximo de miembros 1, puesto que solo puede haber un super usuario que es creado cuando se instala el sistema y no puede ser modificado. Como valores por defecto de privilegios tiene todos los campos a 1, es decir, tiene todos los privilegios sobre todos los objetos.
El grupo NOTREGISTERED, es el grupo al cual son asociados todos los usuarios que no estén registrados, es decir los visitantes, y por defecto tiene todos los valores a 0 , menos aquellos que indican visualización. Resumiendo, pueden ver todo , pero no pueden modificar nada.
Como se ha comentado anteriormente, todo usuario debe estar asociado al menos a un grupo. Para ello se utiliza la tabla membersattachgroups que tiene los siguientes campos: ➢ id_group: id del grupo ➢ id_user: id del miembro ➢ time: fecha de asociación
Esta tabla asocia los usuarios con los grupos, por ejemplo si el usuario con login carlos y con id 1 estuviera en el grupo SUPERUSER con id 1, existiría una entrada en esta tabla como esta: id_group=1 id_user=1 time=xxxxx
Cuando un usuario se registra automáticamente se extrae a todos los grupos a los que pertenece y de esta manera se obtienen los privilegios por defecto, pero esto se verá con más detalle en el punto 3.2.2.7.4 Resolución de privilegios: getPrivileges.
Los grupos AWAITING y BANNED tienen como función el filtrado de usuarios,
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada dado que un miembro que esté en el grupo BANNED nunca podrá registrarse y por tanto siempre será un usuario visitante. Estos grupos tienen todos los privilegios a 0 y son de gran utilidad para el mantenimiento del sistema. Por ejemplo, aunque el sistema posee un mecanismo anti-robot (robots que visitan las páginas, se registran e insertan información de publicidad no deseada, spam ) en la página para darse de alta (imagen de touring), cada vez existen métodos más avanzados para saltarse estos controles. Es una práctica bastante frecuente realizada por SPAMMERs (insertan publicidad no deseada): ejecutan robots que se registran en los sistemas automáticamente e insertan propaganda en su interior. Si se tiene activado el mecanismo de activación de cuenta, los usuarios no pueden registrarse hasta que no activen la cuenta mediante un email que el sistema envía automáticamente al usuario; y que contiene un link de activación. Desde el momento de darse de alta hasta que el usuario activa la cuenta , dichos miembros pertenecen al grupo AWAITING. Esto permite a los administradores filtrar a dichos usuarios y comprobar que no ha activado la cuenta pasado un tiempo o desde donde se ha realizado el registro, pudiendo borrar y limpiar dichos usuarios que sean sospechosos.
3.2.2.7.3 Tabla de privilegios
Los privilegios se aplican a los diferentes objetos del sistema. En este apartado se detalla qué privilegios tiene cada objeto y su significado.
Sobre el objeto Sistema: ➢ admin_soft: Administración leve del sistema, se tiene acceso al panel global de control, pero sólo a las zonas de control de foros, usuarios y grupos. ➢ admin_hard: Administración del sistema, se tiene acceso completo al panel global de control. ➢ admin_full: Administración total del sistema, se tiene acceso completo al panel global de control y se pueden crear super administradores o grupos con
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
privilegios iguales , esta variable solo está activa para el miembro del grupo SUPERUSER. ➢ create_forum: Se pueden crear nuevos foros o cursos en el sistema, eso implica poseer permisos de moderación sobre estos foros y control de grupos para las mátriculas, para conocer con más detalle estos grupos ver 3.5 Panorámica del sistema completo. ➢ create_calendar: Permiso para crear calendario personal. ➢ create_profile: Permiso para crear perfil avanzado de usuario. ➢ ninbox_search: Permiso para utilizar el buscador centralizado Ninbox. ➢ view_profiles: Permiso para visualizar los perfiles de miembros. ➢ view_glosary: Permiso para visualizar el glosario del sistema
Sobre objeto Foro: ➢ Visible: Privilegios de visualización de dicho foro, si esta variable se encuentra desactivada el foro no será visible y no se aplicará ninguno de los siguientes privilegios. ➢ hard_mod: Permisos de moderación total, eso implica borrado físico de contenidos y control de grupos de usuarios. Además se pueden crear subforos en dicho foro. ➢ soft_mod: Permisos de moderación leve, sólo se permite borrado lógico de contenidos. ➢ view_threads: Permisos para visualizar los contenidos de los hilos del foro ➢ view_notices: Permisos para visualizar los hilos especiales del foro. ➢ create_threads: Permisos para crear nuevos hilos en el foro. ➢ create_posts: Permisos para crear respuestas en los hilos del foro. ➢ edit_own_threads: Permisos para editar sus propios hilos. ➢ edit_own_posts: Permisos para editar sus propias respuestas. ➢ rate_threads: Permisos para puntuar los hilos del foro. ➢ direct_threads: Permisos para insertar directamente hilos o bien pasar a
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
la cola de moderación, donde los moderadores deben primero dar por bueno el hilo antes de ser insertado. ➢ direct_posts: Permisos para insertar directamente las respuestas o bien pasar a la cola de moderación, donde los moderadores deben primero dar por buena la respuesta antes de ser insertada. ➢ Ncode: Permisos para insertar Ncode en las respuestas, para saber más sobre Ncode véase el punto 3.5.2 Editor WYSIWYG. ➢ Images: Permisos para insertar imágenes en las respuestas. ➢ Multimedia: Permisos para insertar elementos multimedia en las respuestas. ➢ Upload: Permisos para copiar archivos en el servidor. ➢ Html: Permisos para insertar código HTML en las respuestas, es aconsejable que esta variable sólo esté activa para SUPERADMINS. ➢ Search: Permisos para utilizar el buscador del foro. ➢ view_attachments: Permisos para visualizar y descargar aquellos archivos que otros usuarios han subido al servidor.
Los privilegios que cada foro tiene asociado a cada grupo se relacionan mediante la tabla privileges_forum cuyos campos son los siguientes: ➢ id_group ➢ id_forum ➢ TODOS LOS PRIVILEGIOS ANTERIORES
Mediante esta tabla se relaciona un grupo con un foro y se aplican unos privilegios concretos, en caso de que no exista entrada para un grupo se utilizan los privilegios por defecto del grupo como se detalla más adelante.
Sobre objeto Hilo: ➢ visible : Permisos para visualizar el hilo ➢ create_posts : Permisos para crear nuevas respuestas en el hilo ➢ create_more_posts : Permisos para crear más de una respuesta en el hilo
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
➢ edit_own_posts : Permisos para editar las respuestas en el hilo
Del mismo modo que los foros, existe una tabla para relacionar los grupos con los hilos y sus privilegios, esta tabla es privileges_thread y sus campos son: ➢ id_group ➢ id_thread ➢ TODOS LOS PRIVILEGIOS ANTERIORES
Si un grupo no tiene entrada de privilegios para un hilo , se utizan los privilegios del foro contenedor. Es decir se heredan los privilegios. Esto también ocurre con los subforos.
Sobre objeto Calendario: ➢ visible : Permisos para visualización del calendario ➢ create_posts : Permiso para crear nuevas entradas en el calendario
Si el usuario es un SUPERADMIN además tendrá permisos para insertar entradas especiales, como son ejecuciones automáticas del robot y tareas de administración. La tabla que relaciona los calendarios con los grupos y sus privilegios es privileges_calendar y es similar a la tabla privileges_thread.
3.2.2.7.4 Resolución de privilegios: getPrivileges
La resolución de permisos y almacenamiento en variables para su posterior uso se realiza en el método getPrivileges de la clase Ninbox. Dicho método es llamado en todas las páginas del sistema, justo después de la llamada a checkRegister y antes de comenzar la lectura de datos de entrada y procesamiento.
El planteamiento de resolución de privilegios es el siguiente: Obtener todos los grupos a los que pertenece el usuario, en caso de que sea más
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada de un grupo los privilegios totales por defecto, es decir los de grupo, se calculan mediante un OR de los campos de cada grupo. De esta manera si un usuario pertenece al grupo REGISTERED y al grupo SUPERADMIN, los privilegios totales serán los del grupo SUPERADMIN, prevaleciendo siempre 1 sobre 0 en los campos. La consulta que extrae todos los grupos de un miembro es la siguiente: SELECT g.* FROM membersattachgroups AS m JOIN groups as g on m.id_group=g.id WHERE m.id_user =".$this->session->getData('iduser'),'ASSOC')
Se realiza una consulta en la tabla membersattachgroups, tabla que es usada para relacionar las tablas members y groups. En la consulta se realiza una unión con la tabla group mediante el campo id del grupo y se utiliza como discriminador la id del usuario actual.
A partir de los permisos de grupo se extraen los privilegios de sistema, es decir, aquellos campos relacionados con sistema que se detallaron anteriormente. A continuación se realiza una creación del mapa del sistema al cual se tiene acceso, en primer lugar se genera una consulta en la tabla forum de tal manera que se muestren todos los foros y además se cree una entrada de cada foro por cada grupo. Es decir, si existen dos foros en el sistema y el usuario pertenece a dos grupos la salida que se desea es la siguiente: foro1 grupo1 foro1 grupo2 foro2 grupo1 foro2 grupo2
Esto nos permite por cada foro realizar un OR de los privilegios de cada grupo, en el ejemplo anterior, si grupo 2 no tiene permisos para acceder a foro1, pero grupo 1 si, la resolución para este usuario debe ser positiva, si debe tener acceso a foro1. La consulta que produce esta salida es la siguiente:
SELECT f.id as id_total,f.name as name,f.id_parent as id_parent,pf.* FROM forums AS f JOIN membersattachgroups AS m LEFT JOIN privileges_forum AS pf ON m.id_group = pf.id_group ON f.id = pf.id_forum WHERE m.id_user =".$this->session- >getData('iduser')." AND f.deleted!=1 ORDER BY f.id ASC
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Se realiza una consulta sobre la tabla forum, unida con membersattachgroups, que permite relacionar usuario y grupos, unida con condición LEFT con privileges_forum. Esta tabla posee las entradas de los privilegios que tiene cada grupo sobre cada foro. Las tablas están unidas mediante el id del grupo y el id del foro, el descriminador que se utiliza es el id del usuario de la tabla membersattachgroups y que el foro no esté borrado, finalmente se ordenan en sentido ascendiente mediante el campo id de forum. La salida de esta consulta aplicada al ejemplo anterior es la siguiente: foro1 grupo1 privilegios11( grupo1 sobre foro1 ) foro1 grupo2 privilegios12( grupo2 sobre foro1 ) foro2 grupo1 privilegios21( grupo1 sobre foro2 ) foro2 grupo2 privilegios22( grupo2 sobre foro2 )
Se realiza un OR de privilegios por foro quedando la siguiente tabla: foro1 grupo1 privilegios foro2 grupo2 privilegios
En este OR existen diferentes posibilidades. Existen dos tipos de foros, uno son los foros absolutos, es decir aquellos cuyo campo id_parent=0, que quiere decir que no están dentro de ningún otro foro. Los otros tipos de foros, serían catalogados como subforos, el campo id_parent es igual al id del foro que los contiene.
Además existe otra posibilidad; y es que en la tabla de entradas de privilegios a foros, privileges_forum, no exista entrada que relacione un grupo con un foro. Este sistema de privilegios economiza espacio y tiempo de procesamiento. Si no existe entrada se toma como valor los privilegios por defecto. Es decir si un foro absoluto no tiene entradas de privilegios relacionadas con un grupo (en la consulta anterior los valores serían NULL) se toman como valores los privilegios por defecto del grupo. De esta manera si un grupo se crea como administrador (con todos los permisos de administración) lo será en todos los foros por defecto mientras no se diga lo contrario.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Además para decir lo contrario, es decir crear una entrada de un grupo relacionada con un foro, se debe pertenecer a un grupo de administración que esté en el rango de administración por encima del grupo al que se desea modificar.
El último caso que se puede observar, es el caso en el que un subforo no tenga entrada relacionadas con un grupo, en este caso no se toman los privilegios por defecto del grupo si no que hereda directamente los privilegios del foro padre. Los privilegios se heredan, y esto también ocurre con los hilos. Si un grupo tiene sobre un foro absoluto los permisos de administración , los tendrá sobre todos los subforos, a no ser que un administrador superior haya indicado explícitamente lo contrario. Existe un privilegio que se hereda siempre. Es la visibilidad. Si un foro absoluto es no visible, lo serán también todos sus subforos e hilos aunque esté indicado lo contrario. De esta modo una vez que se termina de calcular todos los privilegios de todos los foros se construye un mapa completo de acceso al sistema, que permite construir un menú de navegación como el que se muestra a continuación:
Figura 10: Menú de navegación de foros
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Además a partir de este mapa se tiene un control absoluto de las zonas a las que puede o no puede acceder el usuario. En modo de resumen, se presenta un esquema donde se resumen la resolución de privilegios sobre un caso hipotético y con los campos privilegios reducidos por simplicidad.
Figura 11: Resolución de privilegios
Todos los OR se realizan a través del método de la clase Ninbox:
public function setMask($parray,$darray,$offset=0) $parray= Array de datos de entrada $darray= Array de valores por defecto $offset= Valor de campos a obviar en el Array de entrda
Este método utiliza a la vez el método de la clase Ninbox:
public function ORArray($array,$offset,$index=NULL) $array= Array para hacer el OR
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
$offset= Offset para la generación de la tabla resultado $index= En caso de ser distinto a NULL, índice que se usará en las tablas resultado
Como conclusión se ha utilizado una estructura de privilegios que permite una infinita variedad de posibilidades, ofreciendo a los administradores un sistema seguro y versátil. Además se ha diseñado de manera que se economice en espacio y tiempo de procesamiento la resolución, gracias a los valores por defecto de grupos y la herencia directa.
3.2.2.8 Otros aspectos del nucleo
3.2.2.8.1 Introducción
En este apartado se detallan otros aspectos del nucleo como son la internacionalización de archivos y el sistema horario. Una de las clases, GMT se encarga de controlar todas las fechas de inserción y de extracción para conseguir mantener coherente dichas fechas independientemente de la zona horaria en la que el usuario visitante se encuentre. La segunda clase I18n se encarga de proporcionar la codificación correcta del documento dependiendo del lenguaje principal del sistema, además de cargar los diccionarios y realizar las traducciones.
3.2.2.8.2 GMT
La clase GMT está definida en el archivo gmt.php de la subcarpeta phpCore forma parte del denominado núcleo del sistema e instanciada en el método Init de la clase Ninbox. En el constructor se realizan las siguientes operaciones:
$GLOBALS['ninbox']->config['server_gmt']=date('H')-gmdate('H');
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Almacena en la variable de configuración de sistema la diferencia entre la hora de servidor y la hora de zona GMT+0 o Meridiano de GreenWitch. Posteriormente se analizan las variables de sesión de usuario para comprobar en qué zona horaria se encuentra, si es un usuario visitante se utiliza la zona horaria del sistema. También se almacena la variable de usuario detect_summer, en caso de que esta variable esté activa se realizará el desfase de horario en zona de verano si procede.
A continuación se definen los métodos de esta clase que se utilizan en la inserción de datos en la renderización.
public function gmtime()
Devuelve el timestamp actual respecto a GMT+0, este método es utilizado siempre que se inserta un campo en cualquier base de datos, puesto que toda la información es insertada siempre respecto GMT+0, aunque el sistema esté en cualquier zona horaria.
public function tolocaltime($gmtime)
Recibe un timestamp referido a GMT+0 y devuelve ese timestamp referido a la zona horaria del sistema. El siguiente método se utiliza siempre que se muestra alguna fecha por pantalla:
public function setFormat($timestamp,$phrase='yes')
Toma un timestamp y una variable phrase. Si phrase es 'yes' y la diferencia entre el timestamp pasado y el actúal es menor de 2 días devuelve una frase de de tipo : Ayer a las...., Hoy a las...., Hace 5 horas... Si la fecha es anterior o la variable phrase es 'no' simplemente devuelve la fecha formateada según la variable de sesión md de la siguiente manera: mm/dd/yyyy hh:mm:ss o bien dd//mm//yyyy hh:mm:ss En cualquier caso, la fecha que devuelve está desfasada de tal manera que sea acorde a la
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada zona horaria de usuario o de sistema y si la variable de sesión detect_summer está activada agregará una hora más si procede.
Es decir, mediante esta clase , siempre se inserta la fecha respecto GMT+0 y se muestra respecto GMT + x, siendo x el desfase del usuario o sistema.
3.2.2.8.3 I18N
El concepto de I18n hace referencia a la internacionalización de un software. Respecto a internacionalización se entiende como la adaptación del software a la codificación de caracteres adecuados, fechas y traducción de frases a la zona local del visitante.
En la internacionalización del sistema Ninbox intervienen principalmente tres clase:
➢ GMT: como se ha descrito anteriormente adapta las fechas. ➢ HTMLGEN: ajusta la codificación de caracteres del documento y que se verá con más detalle en el apartado 3.3.3 Internacionalización del documento ➢ I18N: carga los diccionarios y proporciona métodos de traducción
Como se ha comentado, la clase I18N posee este nombre por tener una relación cerrada con la internacionalización, pero no es la única clase que interviene en el proceso. La clase I18N está definida en el archivo i18n.php de la subcarpeta phpCore y forma parte del denomidado núcleo del sistema y es instanciada en el método Init de la clase Ninbox.
En el constructor de esta clase se realizan las siguientes operaciones:
Se detecta el lenguaje que se debe utilizar en la generación de contenido, esto se realiza a través de la variable de sesión language. En función de esta variable se carga el diccionario que se encuentra en la subcarpeta languages, dentro de la carpeta raíz model.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
En esta carpeta se encuentran los diferentes diccionarios, por ejemplo, el diccionario de ingles sería le archivo en.lang.
La estructura de estos diccionarios es la siguiente:
//dictionary language="English" encoding="iso-8859-1" version="2.0" Hello World[<=>]Hello World ... La primera línea identifica el idioma y la codificación de caracteres empleada. Las demás líneas son pares clave[<=>]valor. Nótese que las claves son siempre abreviaturas de la frase en inglés. Está diseñado para que ocupe el menor espacio posible reutilizando el mayor número de palabras posible.
En este constructor se crea una variable de instacia, dictionary, que almacena los pares clave-valor. El método : public function get($code) Toma una key de diccionario y devuelve el valor de esa key en el diccionario cargado, si no se encontrase dicha key por cualquier tipo de error en el diccionario devuelve la propia key.
El uso de este método y otros aspectos de internacionalización se verá con más detalle en el capítulo 3.3.3 Internacionalización del documento.
3.2.2.9 Conclusiones
Como se ha visto en los apartados anteriores, el núcleo del sistema consiste en una serie de clases almacenadas por archivos que se inicializan y centralizan en la clase Ninbox. Su función se ha detallado anteriormente y se puede resumir como la de administrar tanto los flujos de información cliente-servidor como los datos referidos al acceso y control de usuarios.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
El núcleo está diseñado de forma que puede ser reutilizado en cualquier sistema realizando pequeñas modificaciones sobre los permisos y algunas variables concretas. Se ha conseguido de esta manera, obtener una base robusta y segura de aplicaciones web, que era una de los objetivos de este proyecto.
A continuación se irán detallando de manera más precisa su empleo, como es la inicialización de dicho núcleo en el sistema.
3.2.3 Integración del núcleo en el sistema
3.2.3.1 Introducción
En este apartado se describe como se integran todas las clases del sistema Ninbox y concretamente la clase principal en el sistema de páginas. Como se dijo anteriormente la inicialización y uso del núcleo es la base de toda página. Para su correcta ejecución se requiere el uso de otras clases que realizan la lectura de las variables de configuración y que simplifican todo el proceso de carga de archivos y adaptación de los mismo.
3.2.3.2 Inicialización del núcleo
Para la inicialización tanto del núcleo como de todas las clases involucradas en su funcionamiento es necesario el fichero init_goblals.php que se encuentra en la subcarpeta phpLibrary . Este fichero es incluido al comienzo de todas las páginas del sistema y su función principal es la de incluir todos los archivos del núcleo y demás para el funcionamiento de la página. Los archivo que en esta versión del sistema se incluyen en init_globals son: ➢ phpLibrary/config.php: se verá a continuación ➢ phpCore/exhandler.php: ver punto 3.2.2.5.2 ExHandler ➢ phpCore/sessions.php: ver punto 3.2.2.4.2 SESSIONS
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
➢ phpCore/debugger.php: ver punto 3.2.2.5.3 DEBUGGER ➢ phpCore/gmt.php: ver punto 3.2.2.8.2 GMT ➢ phpCore/database.php: ver punto 3.2.2.4.3 Database ➢ phpCore/cookies.php: ver punto 3.2.2.4.4 COOKIES ➢ phpCore/control.php: ver punto 3.2.2.6.2 CONTROL ➢ phpCore/auth.php: ver punto 3.2.2.6.3 AUTH ➢ phpCore/headers.php: ver punto 3.3 ComponenteVista ➢ phpCore/i18n.php: ver punto 3.2.2.8.3 I18n ➢ phpLibrary/Smarty/libs/Smarty.class.php: ver punto 3.3 Componente Vista ➢ phpLibrary/htmlgen.php: ver punto 3.3 Componente Vista ➢ phpLibrary/basictemplates.php: ver punto 3.3 Componente Vista ➢ CONTROLLER/xajax/xajax.inc.php: ver punto 3.2.4.2 Clases y archivos ➢ phpCore/ninbox.php: ver punto 3.2.2.3 La clase Ninbox
El primero de los archivos que se incluyen es config.php que se encuentra en la subcarpeta phpLibrary. Este archivo contiene la clase CONFIG que es instanciada en el método Init de la clase Ninbox. En su constructor se carga el archivo de configuración que se encuentra en la subcarpeta config. En este archivo están almacenadas todas las variables de configuración del sistema que previamente han sido configuradas por el administrador en el proceso de instalación o en el menú de administración global, en caso de que existiese. Además se encuentran los datos del servidor MySQL como son la URL del server , el login, el password... Se debe remarcar que este archivo contiene información sensible por lo tanto es obligación del administrador proteger dicho contenido.
La clase config, antes de leer el archivo cambia los permisos gracias a chmod , a continuación lee la información y posteriormente cambia de nuevo los permisos. Si el servidor no permite cambiar los permisos de los archivos se debe incluir un código de encriptación bidireccional para leer estos datos sensibles.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
De esta manera es necesario su ejecución antes que ninguna otra clase, puesto que todas las demás dependerán de todas estas variables de configuración.
El archivo init_globals después de incluir todos estos archivos instancia a la clase Ninbox y ésta a su vez, como se vio anteriormente, crea toda la estructura de API's y clases además de lanzar los controles de acceso, privilegios...
3.2.3.3 Conclusiones
En conclusión, una vez terminada la ejecución de este archivo, están todas las bibliotecas cargadas y el núcleo se ha ejecutado. La línea que comparten todos las páginas que hace posible todo este proceso es la siguiente:
include("phpLibrary/init_globals.php");
A continuación se pasa a describir otra de las partes del modelo de sistema, concretamente la librería que permite el uso de AJAX y que como se puede observar en la lista de archivos insertados por init_globals se encuentra ahí incluida:
CONTROLLER/xajax/xajax.inc.php
3.2.4 Integración de AJAX
3.2.4.1 Introducción
Como se comentó en el punto 2.4.4, AJAX es una unión de diferentes tecnologías que permiten realizar consultas en el servidor sin tener que realizar carga de ninguna página. En el sistema Ninbox, AJAX se utiliza para generar la ayuda de navegación y paneles de administración. Así que realmente AJAX estaría en la sección CONTROLADOR, pero se ha incluido en esta sección una parte, puesto que para integrarlo en el sistema se ha utilizado una librería PHP llamada XAJAX, que permite de manera fácil
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada y segura su manejo. Puesto que es código PHP y es cargado en la sección MODELO se ha incluido este capítulo que explique el funcionamiento de dicha librería y su integración en Ninbox. La función de AJAX en la sección CONTROLADOR se verá con más detalle en el apartado 3.4.3 Interacción con el usuario.
3.2.4.2 Clases y archivos
Como se ha introducido, la inserción de AJAX al sistema se ha realizado mediante la librería XAJAX, para tener más detalles sobre la librería ver capítulo 9 Bibliografía.
Es una biblioteca bajo licencia GNU. La biblioteca está contenida en la carpeta xajax de la componente CONTROLLER (subcarpeta de la carpeta raíz model que lleva el mismo nombre). Como se ha comentado anteriormente AJAX pertenece en nuestro modelo al controlador, como se verá con más detalle en dicha sección, pero este capítulo esta incluido aquí por tratarse de código PHP y además por ser requerido en el MODELO del sistema.
El archivo que hay que cargar de la biblioteca es xajax.inc.php, que es incluido en init_globals. La instancialización de la clase se realiza en el método Init de la clase Ninbox, mediante la línea:
$this->ajax = new xajax($GLOBALS['ninbox'] ->config['system_url']."/phpLibrary/ajaxdriver.php");
El constructor de la clase xajax, recibe como parámetro el archivo que será llamado en las consultas realizadas mediante AJAX. Para reflejar un poco mejor la situación en la que nos encontramos se incluye el siguiente esquema:
En el caso de que no se use AJAX nos encontraremos en la siguiente situación:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 12: Web sin AJAX
En cambio el siguiente esquema resume el uso de AJAX en la web:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 13: Web con AJAX
Como se puede observar en este caso, se realiza una consulta asíncrona con en el servidor. No sigue el flujo normal de consulta, puesto que no se solicita a servidor ninguna página, sino que se realiza una consulta a un script en concreto y su salida es devuelta directamente al navegador.
La clase XAJAX genera todo el contenido JavaScript necesario para su procesamiento , pero esta parte se verá con más detalle en el capítulo 3.4 Componente Controlador.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Todas las consultas realizadas mediante AJAX se centralizan en el fichero ajaxdriver.php que se encuentra en la carpeta phpLibrary . Este archivo incluye también la biblioteca XAJAX, además se incluye el archivo ajaxLibrary que se explica a continuación. Posee una única función:
function driver($type=NULL,$valor=NULL)
Los parámetros que recibe son el tipo de consulta y posibles parámetros de la consulta. Por ejemplo para consultas de ayuda la variable type es help y la variable valor es el código del elemento del que se desea buscar ayuda. En el interior de esta función se realiza esta operación:
eval("\$result=".$type.'("'.$valor.'");');
Es decir se evalua una cadena de texto compuesta por las variables que recibe, en el caso de la ayuda la instrucción que se ejecutaría sería por ejemplo:
$result=ayuda('crear_post');
De esta manera se llamaría a la función help que es la encargada de buscar en los archivos o bases de datos la ayuda pertinente y devolver la cadena. Todas las funciones para el tratamiento de consultas, como por ejemplo help, se encuentran en el fichero ajaxLibrary.php de la subcarpeta phpLibrary. Una vez realizada la consulta se debe devolver la información mediante XML, todo este proceso es llevado a cabo por la librería XAJAX. Se muestra a continuación una línea de este proceso:
$objResponse->addAssign("ajaxinbox_content_innerhtml", "innerHTML", $result);
Genera información XML que será interpretada en el código Javascript generado a su vez por la librería XAJAX para que inserte en una capa la información de ayuda.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
$objResponse->addScriptCall("AJAX_loaded");
Genera información XML que será interpretada en el código Javascript generado a su vez por la librería XAJAX para que realice una llamada a una función JavaScript.
La última de las llamadas del archivo ajaxdriver es la siguiente:
$xajax->processRequests();
En este momento la librería XAJAX es la encargada de toda la codificación XML y su envío al cliente. A continuación se verá como influye todo este proceso en el rendimiento y la interacción con el usuario.
3.2.4.3 Repercusión en la interfaz: Usabilidad
Se ha decidido utilizar AJAX para operaciones muy concretas y aisladas del sistema, concretamente para el sistema de ayuda y para los menús de administración. Esta decisión se ha basado en que para la navegación normal del sistema se prefiere un control de flujo lineal, para asegurar un comportamiento correcto. Además, de esta forma se asegura tener un control más exhaustivo y una mejor interpretación en el navegador.
Otro de los motivos es que el sistema está diseñado para que sea visualizado en cualquier navegador, y hoy en día aún existen navegadores que no aceptan los HTTPRequest o que por ejemplo tienen desactivado la ejecución de JavaScript. Por este motivo su uso ha sido destinado a zonas muy controladas y precisas que no alteren la visualización normal del sistema.
Se ha demostrado empíricamente que AJAX introduce retardos considerables en consultas de gran volumen, dado que la carga de una página completa puede suponer un envío grande de información podría ocasionar una sensación lenta y pesada en la navegación.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Por contra se ha decidido utilizar AJAX en el sistema de ayuda porque como se ha explicado antes, AJAX permite transferir menos información en consultas pequeñas, y dado que la ayuda son pequeños volúmenes de información se ajusta perfectamente a su uso, proporcionando un efecto agradable en su uso, dado que el usuario puede consultar la ayuda sin cargar ninguna página nueva.
Para los menús de administración, parte no implementada en este proyecto, también resulta aconsejable su uso, puesto que permite generar menús completos, además de realizar consultas y operaciones asíncronas en el servidor sin tener que cargar nuevas páginas, pudiendo navegar en el menú de administración de manera independiente a la web.
3.2.4.4 Conclusiones
Existen diferentes bibliotecas como XAJAX, que proporcionan los mecanismos y códigos necesarios para insertar AJAX en una web. No obstante XAJAX ha sido elegida por proporcionar códigos servidor en PHP que facilitan aún más la tarea y proporcionar unos códigos Javascript del lado del cliente que cumplen con todos los estándares necesarios para un correcto funcionamiento en todos aquellos navegadores que permiten realizar HttpRequest.
Por otra parte cabe destacar que el uso de AJAX, muy extendido en los últimos años, es una tarea que debe ser realizada con sumo cuidado, puesto que aunque las ventajas de su uso son evidentes, como la interacción del usuario con la web como si de un software de escritorio se tratase, se pueden introducir otros problemas. Entre estos problemas se encuentran: la perdida de sensación de navegación lineal a la que el usuario está acostumbrado, es decir, si AJAX se utilizase para la carga de todas las páginas, el navegador nunca se trasladaría de URL y el usuario podría no utilizar el botón Atrás del navegador. Existen mecanismos que solucionan este problema como es la inserción de un iframe oculto en el cual se va insertando las URL's hipotéticas a las que se
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada desplazaría el navegador, de esta manera , cuando se pulsa Atrás en el navegador el iframe vuelve a la URL anterior y se captura en el frame principal actuando en consecuencia. Otro de los problemas asociados al uso de AJAX son los tiempos de retraso, obviamente existe un tiempo entre que el usuario pulsa un botón y la información vuelve y cambia la interfaz, estos tiempos fluctúan dependiendo de la cantidad de información transmitida y puede producir el efecto de no reacción ante la acción del botón. Por este motivo es aconsejable siempre utilizar mensajes de feedback para mantener al usuario en todo momento informado de que su solicitud está siendo tramitada.
Después de muchos estudios y comprobaciones , se ha decidido usar AJAX en aquellas partes en las que su inserción produzcan un beneficio absoluto y no un posible problema a la hora del uso del sistema, teniendo en cuenta siempre la pluralidad de navegadores que existe en el mercado y las diferentes posibilidades de cada usuario.
Como conclusión, el uso de AJAX ha proporcionado grandes ventajas al sistema Ninbox, puesto que la sección de ayuda es muy rápida e intuitiva de utilizar, y de igual modo sucedería con el sistema de administración.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.3 Componente Vista
3.3.1 Introducción
Como se comentó al inicio del capítulo 3 , el sistema está dividido en 3 componentes fundamentales: modelo, vista y controlador. En esta sección se estudia la componente vista del sistema. La componente vista del sistema está compuesta por todos los archivos que son necesarios para la generación de la interfaz de usuarios. En la interpretación de la arquitectura MVC realizada en este sistema, estos archivos son básicamente xhtml, css, imágenes, elementos multimedia... Se ha visto oportuno comentar en esta sección las clases y archivos PHP que se utilizan para o bien cargar los contenidos de la componente vista o bien generarlos. Todos los archivos que componen este módulo se encuentran en la subcarpeta VIEW de la carpeta model del sistema.
A continuación se explican los archivos y, en el caso de código PHP, las clases que intervienen.
3.3.2 Clases y archivos
Los archivos necesarios para la generación de la interfaz web de usuario se encuentran en la carpeta VIEW y pueden clasificarse de la siguiente manera: ➢ Hojas de estilo: se encuentran en la carpeta css. ➢ Imágenes: se encuentran en la carpeta images. Son imágenes, principalmente jpeg que ayudan a generar elementos de la interfaz amigable. ➢ Archivos XHTML: se encuentran en la carpeta templates. Son archivos tpl con contenido xhtml que componen las diferentes partes de la web. Son utilizados por el sistema de plantillas PHP Smarty para inyertar el valor de variables directamente en
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
la plantilla. De esta manera se puede diseñar la apariencia por un lado ( código XHTML+imágenes+css) y cargar dicha plantilla en la clase smarty e inyectar el valor de las variables para de esta manera generar páginas dinámicas.
Como se ha comentado anteriormente, para la generación de dicha interfaz es necesario la ejecución de cierto código en el servidor, es decir, archivos PHP. A continuación se describen los archivos y clases que intervienen en la generación de la vista del sistema.
Archivo headers.php: archivo del core del sistema. Contiene la clase HEADER, encargada de escribir las cabeceras HTTP que recibirá el navegador. Es instanciada en la clase Ninbox, método startOuput, ejecutado justo antes de la generación de la interfaz.
Archivo htmlgen.php: archivo en la carpeta phpLibrary. Contiene la clase HTMLGEN, encargada de escribir la cabecera XHTML, incluir el código encargado de cargar los archivos js,css... , crear el cuerpo de la web, cerrar el documento web. En definitiva, ayuda a generar un documento XHTML bien formado. Es instanciada en la clase Ninbox, método startOuput, ejecutado justo antes de la generación de la interfaz. Los métodos para la inclusión de código son llamados directamente en cada página en los momentos requeridos.
Archivo basictemplates.php: archivo en la carpeta phpLibrary. Contiene la clase basictemplates, dicha clase extiende a la clase Smarty de la librería PHPsmarty. Esta librería se utiliza, como se explicó anteriormente, para poder maquetar los archivos XTML, almacenados en archivos tpl, de manera independiente. Posee una serie de instrucciones que se deben insertar entre el código normal XHTML que ayudan a la librería a reconocer cuando deben inyectar el valor de una variable PHP o bien realizar un bucle...
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
La clase basictemplates, además de realizar las operaciones de la librería PHPSmarty, proporciona métodos concretos para cargar templates específicos de bloques comunes. Por ejemplo, todas las páginas comparten el cuadro dónde se indican los privilegios de los usuarios, existe un método que carga dicho template, e inyecta los valores adecuados para su correcta generación, mostrando con texto e imágenes los permisos de cada usuario.
La clase basictemplates es instanciada en el constructor de la clase Ninbox, y los métodos son llamados en el momento de generar el elemento deseado.
Básicamente con estos archivos se genera todo el código que se envía al navegador del cliente y que compone el módulo vista. La utilización de estas 3 clases , hace posible una total división entre código PHP ( servidor ) y archivos de la componente vista.
3.3.3 Internacionalización del documento
Para la generación de texto se utiliza una clase intermedia, llamada I18N, encargada de cargar el diccionario correspondiente , según el valor de la variable de sesión language. Los diccionarios se encuentran en la subcarpeta languages de la carpeta principal model. En estos momentos existen tres diccionarios: ➢ en.lang ➢ sp.lang ➢ it.lang Correspondientes con el diccionario inglés, español e italiano respectivamente. Los diccionarios están formados por diferentes líneas ( casa línea es una palabra o frase a traducir ) y cada línea compuesta por la siguiente estructura: Identificador_de_frase<=>Traducción de frase o palabra al lenguaje adecuado
La clase I18N se encuentra en el archivo i18n.php del nucleo. Es instanciada en
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada el constructor de la clase NINBOX. Carga el diccionario y construye una variable de instancia llamada dictionary.
El método get de la clase I18N recibe el identificador de frase devuelve la traducción o el propio identificador si no se encuentra recogida en el diccionario. De esta manera, siempre que se inyecta valor de variables en la interfaz de usuario, ya sea mediante la clase basictemplates o cualquiera de los otros métodos que producen salida en el navegador, todas las variables son antes pasadas al método get para que se imprima el mensaje en el lenguaje adecuado.
3.3.4 Conclusiones
El diseño de la componente vista está pensado para conseguir una división completa entre diferentes códigos y funciones. Consiguiendo de esta manera tener una buena estructura que ayude a actualizar, por ejemplo la interfaz sin tener que tocar código PHP de servidor o Javascript de cliente y viceversa.
Las clases y funciones que comunican PHP con la generación de interfaz proporcionan mecanismos limpios y efectivos para la composición de documentos bien formados que cumplan todos los requisitos de la W3C. Por último cabe señalar, que la clase I18N y en general el sistema de diccionarios, están diseñados para utilizar el mínimo espacio en memoria posible y la mayor rapidez en consulta, reutilizando en el mayor caso posible términos o partes de expresiones.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.4 Componente Controlador
3.4.1 Introducción
En esta sección se detalla la componente controlador que supone la última parte de la arquitectura MVC del sistema Ninbox.
Como se explicó al inicio del capítulo 3, el modelo MVC utilizado en este proyecto es una adaptación del mismo a la situación particular de la aplicación y el lenguaje utilizado. En otros sistemas este módulo difiere bastante al aplicado en este caso. En el sistema Ninbox se ha visto oportuno definir la componente controlador, como el conjunto de archivos que interactúan entre el usuario y el servidor. Esta interacción se realiza directamente mediante el navegador web del cliente. De esta manera, este módulo esta compuesto principalmente por archivos Javascript que son ejecutados en el navegador del cliente.
3.4.2 Clases y archivos
Todos los archivos y clases Javascript que componen este módulo se encuentran en la subcarpeta CONTROLLER de la carpeta model.
Los principales archivos Javascript son los siguientes: ➢ main.js: esta compuesto de las funciones principales ejecutadas por el cliente en el navegador, como son redireccionamiento de la página, recarga... ➢ ajax.js: funciones encargadas del control de la capa que se utiliza para mostrar la ayuda interactiva del sistema. Para todo el sistema de ayuda se utiliza AJAX en la carga de la misma. Este archivo ofrece las funciones de ocultar, minimizar, mostrar... la capa de ayuda.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Para funciones avanzadas de generación de efectos sobre elementos html se ha incorporado la librería Javascript Scriptaculous. Dicha librería se basa en el framework de Javascript prototype. Este framework gratuito y “open source” proporciona métodos que facilitan el uso de Javascript.
3.4.3 Interacción con el usuario
La componente controlador es una parte esencial en la composición de una interfaz adecuada, proporcionando al usuario mecanismos de “feed back”, es decir mensajes de información ya sea de respuesta de peticiones o de estado del sistema. Además se pueden añadir funciones avanzadas como menús interactivos que faciliten el uso de la web.
En la creación de interfaces de aplicación y especialmente en sistemas web, es fundamental un diseño basado en la accesibilidad y usabilidad. Respecto al primer término, accesibilidad, hay que tener en cuenta que algunos usuarios, principalmente aquellos que utilicen equipos antiguos o con software para discapacitados, tendrán la ejecución de Javascript desactivado. Por este motivo, siempre se debe realizar la interfaz web de tal manera que esto no provoque la inhabilitación de las tareas principales de navegación (proporcionando links html normales). Además para usuarios con Javascript activado, dependiendo de la versión de navegador web que utilicen se puede obtener un resultado u otro, o incluso error derivado de la ejecución de Javascript. Por este motivo, siempre hay que programar este código teniendo en cuenta el mayor abanico posible de navegadores. Ninbox está probado bajo los siguientes navegadores: ➢ IE 5.5+ ➢ Firefox 1.5+ ➢ Netscape ➢ Opera
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Respecto al termino usabilidad, el uso de Javascript de manera adecuada puede proporcionar los mecanismos idóneos para introducir elementos de navegación, información y control necesarios para generar un efecto continuo, intuitivo y agradable en el uso del sistema.
3.4.4 Conclusiones
Como se ha explicado anteriormente, la definición de esta componente controlador es la que más controversia puede producir, puesto que no es habitual relacionar controlador con Javascript. No obstante se reitera en este apartado la efectividad de diseño e implementación conseguidos con este mecanismo.
Además de conseguir separar completamente otro lenguaje de programación, Javascript, de los demás, se ha conseguido separar el código ejecutado en cliente. Este código como se ha explicado en el apartado anterior puede ser muy sensible, dado que algunos comandos son interpretados de manera distinta por los diversos navegadores.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.5 Otras aplicaciones integradas
3.5.1 Introducción
En este aparto se detallan otras aplicaciones que han sido desarrolladas para este proyecto que son integradas en el sistema Ninbox. Cada una de estas aplicaciones funcionan por sí mismas y han sido insertadas en la componente MODELO de esta documentación porque son requeridas por los archivos del modelo del sistema. Estas aplicaciones llevan a su vez cada una una componente modelo, vista y controlador para generar el procesamiento y creación de la interfaz adecuada.
Una de las aplicaciones es un editor WYSIWYG que sirve como punto de interacción entre el usuario y el sistema. A partir de esta aplicación se inserta toda la información en el sistema, por este motivo es de vital importancia su desarrollo correcto. La otra aplicación es una webConference cuya función principal es la de proporcionar un aula digital en la cual se imparta una clase pseudo-presencial en la que se permite una mayor interacción entre profesor y alumnado.
3.5.2 Editor WYSIWYG
3.5.2.1 Introducción
Un editor WYSIWYG ( What You See Is What You Get ) es una aplicación que permite la inserción y maquetado de texto en línea, viendo en tiempo real los resultados. Es decir los usuarios pueden generar texto enriquecido, insertar imágenes, multimedia, sin tener que conocer el código HTML que se necesario para ello, simplemente como si de un procesador de textos se tratase.
Existen muchas aplicaciones con dicho propósito, pero se ha decidido
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada desarrollar una propia que se ajuste óptimamente a las necesidades de este sistema. Como se verá en los siguientes puntos permite la inserción de elementos multimedia, elementos XHTML y texto formateado realizando una conversión de código XHTML a Ncode antes de ser insertado en la Base de Datos.
A continuación se explica qué es el código Ncode y por qué se utiliza.
3.5.2.2 Ncode
Ncode está basado en el código BBCode. Dicho código, proveniente del inglés Bulletin Board Code es un pequeño lenguaje usado en los foros para cambiar y editar la forma en que un mensaje (post) es mostrado. BBCode es una colección de marcadores de formato que se usan para cambiar la apariencia del texto en un foro. BBCode está basado en el mismo principio que HTML.
Este código de maquetación de textos e imágenes mediante etiquetas fue creado por PhpBB para sus propios foros y finalmente se ha difundido en la gran mayoría de los foros web.
Como se ve en los apartados siguientes, un editor WYSIWYG genera código XHTML y si se inserta directamente este código podría generar un hueco de seguridad, puesto que se podría insertar código malicioso. En cambio con este mecanismo, todo el código XHTML permitido es traducido a Ncode y aquel que no es permitido se deshabilita escapando los caracteres especiales, como por ejemplo: <, >...
De esta manera, se aseguran dos cosas, el código insertado siempre es seguro, puesto que es un código que no es interpretado por los navegadores, y si el editor no arranca porque el usuario tenga Javascript desactivado podrá insertar código enriquecido utilizando las etiquetas de Ncode que son sencillas y además se proporciona una ayuda completa en el sistema.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
A continuación se muestra el resumen de etiquetas Ncode existentes en el sistema:
[b]texto[/b] : Poner en negrita, equivale a [i]texto[/i]: Poner en cursiva, equivale a [u]texto[/u]: Poner subrayado, equivale a [left]texto[/left]: Alinear texto a la izquierda, equivale a
[center]texto[/center]: Alinear texto al centro, equivale a [right]texto[/right]: Alinear texto a la derecha, equivale a [ul][li]opcion[/li][/ul]: Listado no ordenado, equivale a- [ol][li]opcion[/li][/ol]: Listado ordenado, equivale a
- [blockquote]texto[/blockquote]: Tabular un texto, equivale a [sub]texto[/sub]: Insertar un subíndice, equivale a [super]texto[/super]: Insertar un superíndice, equivale a
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
[media ]url[/media]: Insertar elemento multimedia, realiza una traducción de código dependiendo de la url, si es un video genera un reproductor de video, si es de audio ... Si no se conoce el formato genera un link a la propia URL introducida. Los formatos que se permiten son: mov, mp3, mpg, mpeg, qt, mqv, m1s, m1v, m1a, m75, m15, mp2, mpm, mpv, mpa, 3gp, 3gpp, 3g2, 3gp2, sdv, amc, mp4, sdp, avi, flv, swf, URL a youTube, a Google Video, URL a Meta café.
El resultado puede verse en el apartado 5.4 Ejecución del editor WYSIWYG.
3.5.2.3 La Clase wysiwyginbox
Como se comento anteriormente, el editor WYSIWYG es realmente un elemento de la componente CONTROLADOR del sistema puesto que es un script que se ejecuta en el cliente y que afecta a la interacción cliente-sistema. No obstante se incluye en este apartado del modelo porque se considera un elemento vital para su funcionamiento y es en sí una aplicación.
La clase wysiwyginbox se encuentra en el archivo ninbox.js en la carpeta WYSIWYG de la componente CONTROLLER. Es un archivo de código Javascript y por tanto sobre este lenguaje esta construida dicha clase. Esta clase se instancia en la sección de código Javascript en las páginas se desea inciar el editor. Los parámetros que toma como entrada son el ID del campo textarea que se desea reemplazar, así como el tipo de interfaz que se desea arrancar, los permisos de insercción de código HTML...
Su funcionamiento consiste en rastrear el documento XHTML como estructura DOM y detectar el textarea que se desea reemplazar, también existe la posibilidad de ejecutar un método de dicha clase para reemplazar todos los textareas del documento.
A continuación se muestra las instrucciones de arranque del editor:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Este código se inserta entre las etiquetas HEAD del documento y se ejecuta la función initEditor que prepara la variable config para configurar los parámetros de arranque del editor. En la clase, como se dijo anteriormente, se busca el textarea a sustituir. El textarea es un elemento HTML que se utiliza en formularios para introducir información. Este elemento sólo permite insertar texto plano. Por este motivo se toma el padre de dicho textarea y se inserta en su interior una capa, posteriormente en el interior de dicha capa se crea un iframe y se mueve el textarea al interior de la capa creada justo después del iframe. El iframe es un elemento HTML que sirve para insertar páginas externas dentro de un documento. No obstante tiene un método que habilita al iframe como editor:
doc.body.contentEditable para IE y Opera doc.designMode para Mozilla
De este modo se puede ejecutar sentencias sobre el iframe para maquetar el texto que se introduce en él, como por ejemplo:
editor._doc.execCommand('createlink',false,url);
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Crea un link con url sobre el elemento editor que contiene al iframe. De este modo tenemos un editor WYSIWYG, para acceder al contenido HTML que se está generando solo se tiene que acceder al contenido de la variable innerHTML del iframe.
La clase wysiwyginbox, además, crea un menú superior para facilitar todas las operaciones de maquetado y proporciona detectores de eventos para capturar la información del iframe antes de que se envíe el formulario en el que estaba insertado el textarea original y poder así actualizar su contenido antes de ser enviado. El textarea original nos sirve para conmutar el modo WYSYWYG y NCODE. En el modo WYSIWYG el editor funciona normalmente, sin embargo, en el modo NCODE se oculta el iframe y se pone visible el textarea que antes estaba oculto. Se toma el código HTML del iframe y mediante el uso de expresiones regulares se hace una traducción de código y posteriormente se inserta en el textarea. De este modo, en caso de no soportarse los iframes podrá seguir usándose el editor.
A continuación un esquema que sintetiza esta situación:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 14: Textarea en formulario La ejecución de la clase wysiwyginbox genera la siguiente situación:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 15: Estructura HTML del editor WYSIWYG
La traducción de código HTML a Ncode se realiza mediante las expresiones regulares. Por ejemplo la siguiente instrucción:
content=content.replace(/(\[b\])((.(?!\1))+)(\[\/b\])/gi,'$2'); Reemplaza en la variable content , que contiene el código Ncode, todas las expresiones [b] texto que no contenga [b] [/b] por texto original . La siguiente expresión:
content=content.replace(/(\[face=(\")*([\w\- \,\s]+)(\")*\])((.(?!(\[face=(\")*([\w\- \,\s]+)(\")*\])))+)\[\/face\]/gi,'$5');
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Reemplaza en la variable content, que contiene el código Ncode, todas las expresiones [face= seguido opcionalmente de “ y a continuación una serie de letras o espacios en blanco, donde se almacena la fuente del texto. Justo después se busca un carácter “ opcional y posteriormente ], se comprueba que exista un [/face] y que entre esta última y la primera etiqueta no exista ninguna etiqueta sobre formateo de fuente. Si se encuentra esta expresión se sustituye por el texto original que estaba entre etiquetas y .
De esta manera compleja, pero a la vez rápida y efectiva se realizan todas las transformaciones entre códigos. Más información sobre el código empleado puede verse en el apartado 7.3 Código Javascript.
3.5.2.4 Integración y uso
La integración del editor es sencilla y rápida, tan sólo se deben añadir unas líneas de código para arrancar la clase wysiwyginbox y pasar como parámetro el id del textarea a reemplazar. Automáticamente la conversión será realizada y el editor estará preparado para ser utilizado.
La apariencia final del editor dependiendo de la hoja de estilos que tenga puede ser como la siguiente:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 16: Ejemplo del editor WYSIWYG
Su uso resulta fácil e intuitivo, puesto que su manejo es similar al de cualquier procesador de textos, simplemente seleccionar el texto a formatear y pulsar el botón de formateo deseado.
Proporciona además unos botones que permiten aumentar el tamaño vertical del editor para que resulte más cómodo la inserción de texto de gran longitud.
En el ejemplo de la figura anterior si se pasara el editor a modo Ncode, es decir si se oculta el iframe, se toma su contenido HTML, se realiza la traducción a Ncode, se hace visible el textarea y se inserta la información anterior en su interior resultaría lo siguiente:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 17: Ejemplo de editor WYSIWYG en modo NCode
Para saber más sobre el editor en funcionamiento ver el apartado 5.3 Ejecución del editor WYSIWYG.
3.5.2.5 Conclusiones
Como se verá en el capítulo de pruebas, el editor funciona sobre Opera, Mozilla, Internet Explorer y Netscape. Esto resulta todo un éxito puesto que se presenta como uno de los únicos editores WYSIWYG de su tipo que funciona en todos estos navegadores. Además, en caso de que se ejecute en navegadores que no permitan iframe se ejecutará simplemente en modo Ncode y podrá seguir siendo usado. Si se ejecuta en navegadores que no permitan la ejecución de Javascript simplemente la clase no se ejecutará y quedará el textarea original para insertar texto. De esta forma se asegura la inserción de texto en cualquier caso y en caso favorable una inserción cómoda y elegante que favorece el uso y manejo de información y su estructuración para una óptima presentación.
Su ejecución es rápida y su tamaño en memoria es mínimo, no resultando en ningún caso una aplicación pesada y que entorpezca al navegador del cliente.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.5.3 WebConference: Talkinbox
3.5.3.1 Introducción
El concepto WebConfence se aplica usualmente a aplicaciones web que permiten realizar reuniones virtuales, con el fin de comunicar varios usuarios en tiempo real. Existen empresas que se dedican exclusivamente a servir este tipo de aplicaciones.
Funcionaría de la siguiente manera por ejemplo, una empresa española desea realizar negocios con una empresa japonesa y antes de realizar ningún costoso viaje querrían realizar una reunión virtual. Una de las empresas se pone en contacto con la tercera empresa que sirve webConferences y solicita el servicio para un día y hora concreta, con una duración precisa y unos usuarios también prefijados. La empresa distribuye las passwords y posteriormente las dos empresas iniciales que deseaban mantener la reunión entran en la web el día y hora concretada. Introducen el password y comienza la reunión.
Dependiendo del lenguaje utilizado en su programación y la posibilidad de tener un servidor dedicado se pueden ofrecer servicios como video conferencia, transferencia P2P ...
El sistema Ninbox incluye una aplicación webConference reducida. El lenguaje utilizado para su programación es PHP del lado del servidor y Javascript del lado del cliente. Dado que este sistema está pensado para estar ubicado en servidores compartidos y el proyecto no alberga más posibilidades; los servicios que ofrece la webConference del sistema Ninbox, llamada Talkinbox, son los de comunicación escrita, con posibilidad de
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada control de usuarios. En los siguientes apartados se detalla como está programada, como se integra y cual es su función.
3.5.3.2 Clases y archivos
Todos los archivos que componen la aplicación Talkinbox se encuentran en la carpeta con mismo nombre ubicada en la sección MODELO. Esta carpeta posee el siguiente contenido:
➢ Archivo talkinbox.php: Clase principal del sistema. ➢ Archivo pipe.php: Archivo PHP incluido en un iframe de la página principal, que realiza las funciones de comunicación y actualización con la base de datos. ➢ Carpeta images: Imágenes necesarias para generación de interfaz. ➢ Archivo talkinbox.css: Archivo CSS de maquetado de la interfaz. ➢ Archivo talkinbox.js: Archivo Javascript controlador de la aplicación.
La clase principal talkinbox está contenida en el archivo talkinbox.php. Esta clase carga las variables de sistema y los diccionarios. Posee dos métodos:
➢ public function inhead(), que genera código de cabecera del documento, como es la importación de archivos controlador Javascript y de estilo CSS. ➢ public function inbody(), que genera código de cuerpo del sistema. Es decir todo el código XHTML necesario para la presentación del sistema.
El funcionamiento es el siguiente:
Como se ha comentado anteriormente, se genera en el body del documento todo el código XHTML necesario para mostrar la interfaz, y además se crea un iframe donde se incluye al archivo pipe.php.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
El archivo pipe.php básicamente es un formulario que se crea dinámicamente con los valores a insertar en la base de datos. Cada x segundos este formulario se envía automáticamente a sí mismo, a pipe.php. Pipe.php recoge la información del formulario y la inserta en la base de datos y posteriormente procede a consultar la base de datos para recoger información que aún no haya sido recibida por el usuario. Cuando termina este proceso se genera de nuevo el documento formulario y se devuelve mediante Javascript la nueva información al documento padre que contiene Talkinbox y que actualiza la interfaz.
Resumiendo, un usuario escribe una frase, esta frase se lleva al formulario pipe.php que está oculto, pipe.php se refresca y actualiza la base de datos y aprovecha para recoger nuevas frases de otros usuarios. Para saber que frases no han sido leídas se utiliza el identificador único que posee cada entrada en la tabla y el tiempo de refresco que se almacena siempre como variable de sesión. Además, ofrece la posibilidad de envío de mensajes privados u otras operaciones por parte del moderador, por este motivo cada mensaje que se inserta posee un campo code, que identifica que tipo de mensaje es.
Las tablas utilizadas en el sistema son: ➢ talkinbox_messages : para el envío de los mensajes con código de operación. ➢ talkinbox_security: para recoger posibles usuarios expulsados por el moderador y no permitir su entrada. ➢ talkinbox_session: para almacenar las diferentes sesiones de webConference que existen el sistema y sus moderadores. ➢ talkinbox_slides: para almacenar diapositivas de los moderadores. ➢ talkinbox_users: para controlar usuarios online y su estado.
Para más detalle sobre las bases de datos ver apartado 7.6 Planos de Base de datos. En el siguiente apartado se verá su funcionamiento y se explicará más detalladamente como influyen cada una de las partes.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.5.3.3 Integración y funcionamiento
Para integrar talkinbox tan sólo es necesario instanciar la clase talkinbox en la página y llamar al método inhead en la cabecera del documento y al método inbody en el cuerpo del documento. Una vez realizadas estas operaciones se presenta la siguiente interfaz:
Figura 18: Interfaz básica de Talkinbox
La imagen anterior captura la interfaz principal de la aplicación talkinbox. Existen cinco marcos principales, tres a la izquierda y dos a la derecha. El primer marco a la izquierda es la ventana de mensajería. En esta pantalla se muestra toda la información de intercambio entre usuarios o sistema a usuarios. Justo debajo se encuentra el siguiente marco que contiene al editor WYSIWYG que permitirá a los usuarios insertar la información a enviar. Por ultimo, el marco que sirve para cargar diapositivas predefinidas por el moderador en el editor.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
A la derecha el primer marco es la ventana donde se muestran los usuarios conectados , y menú para interaccionar con ellos como se detalla más adelante. El segundo de los marcos de la derecha es la ventana de estado, donde se detalla toda la información de la sesión actual: minutos que quedan para finalizar, número de usuarios, modo, que puede ser opened ( cualquier usuario podría entrar ) o closed( no daría servicio a más usuarios ). Además muestra un menú de botones para administrador que se explica más adelante. A continuación se describirá el funcionamiento básico de talkinbox:
Para que el sistema dé servicio debe existir una sesión registrada a una hora con un moderador concreto, si se intenta acceder a una sesión no activa o fuera de horario no se iniciará el sistema. Cada sesión tiene un único moderador. Dicho moderador puede cambiar los valores de la sesión en el panel que le aparece en el segundo marco de la derecha.
La sesión se puede establecer en dos modos: ➢ Clase Magistral: Sólo el moderador puede hablar y además nadie puede pedir turno de palabra. ➢ Discusión: Sólo el moderador puede hablar, pero los usuarios pueden pedir turno de palabra, así el moderador puede dar voz a un usuario o a todos a la vez.
Cuando un usuario que no es moderador accede al sistema, la interfaz es la siguiente:
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 19: Interfaz de usuario de Talkinbox Es decir, no posee el editor WYSIWYG ni el panel de diapositivas , ni tampoco el menú de configuración. Si la sesión está establecida en modo Discussion podrá accionar el primer botón que se encuentra en el marco de la derecha para solicitar turno de voz. A continuación, el icono que se encuentra al lado de su nombre comenzará a parpadear y se le enviará un mensaje de sistema al moderador informando de la situación. El moderador podrá dar turno de palabra o quitar o establecer a los usuarios como invitados. Un usuario invitado tiene turno de palabra por defecto y puede entablar conversaciones privadas con usuarios, al igual que el moderador.
Para cambiar las configuraciones del sistema, o actuar sobre el conjunto completo de usuarios el moderador posee la colección de botones que se encuentra en el marco de la derecha.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Para actuar sobre un usuario concreto el moderador de la sesión de webConference posee un menú que aparece después de hacer click sobre el nombre de usuario que se encuentra en la lista de personas presentes en la sesión. Las operaciones básicas que se pueden realizar sobre un usuario concreto son las siguientes: ➢ Ofrecer turno de palabra: en modo discussion le aparecerá el editor WYSIWYG para poder insertar contenido en la webConference. ➢ Quitar turno de palabra. ➢ Establecer como usuario visitante, en cuyo caso siempre posee turno de palabra y puede establecer comunicación privada con los demás usuarios. ➢ Chat privado: consiste en un cuadro de texto en el que el mensaje que se envíe sólo será recibido por el usuario seleccionado. A continuación se muestra una captura del menú de operaciones sobre usuarios:
Figura 20: Menú de usuario de Talkinbox
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.5.3.4 Conclusiones
Talkinbox es una aplicación que proporciona un sistema de comunicación en tiempo real. Es integrable en cualquier servicio web y posee control propio de acceso. Además posee una fácil y sencilla interfaz tanto para moderadores como para usuarios; esta versión reducida de webConference se presenta como un servicio adicional para la educación online.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.6 Panorámica del sistema completo
En este apartado se realiza un estudio del sistema completo de e-Learning que ha sido el objetivo de este proyecto y para el cual se han desarrollado las aplicaciones antes descritas. Para detallar completamente la plataforma Ninbox para e-Learning se ha visto oportuno comenzar este punto con la descripción de un caso de uso, es decir, un ejemplo práctico en el cual se utiliza dicha plataforma.
3.6.1 Caso de uso
En este punto se describe un caso de uso hipotético de la plataforma educativa Ninbox. Todos los enunciados y explicaciones sucesivas en este punto forman parte de un ejemplo y no corresponden en ningún caso con datos o situaciones reales.
La Escuela Técnica Superior de Ingenieros de la Universidad de Sevilla ha decidido implantar un servicio de educación on-Line que proporcione un soporte más para la buena formación de sus alumnos. Este servicio de educación on-Line consiste en una plataforma web (Ninbox) que proporciona un sistema de foros que ordena y categoriza la información y su acceso dependiendo de la carrera que el alumno esté cursando y las materias que aborde. La instalación de la plataforma educativa Ninbox se realizará en uno de los servidores del Centro de Cálculo de la misma escuela y será llevada a cabo por un profesor del departamento de Sistemas y Automática.
En el equipo del centro de cálculo existe instalado un servidor Apache y MySQL con soporte para versiones de PHP 5 y superiores y para MySQL 5 y superiores. La instalación del sistema la realiza el profesor siguiendo los pasos que se describen en el capítulo 4 de este documento (El usuario superadministrador es creado en el momento de la instalación) .
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Una vez el sistema esta completamente instalado, se lleva a cabo la configuración del mismo. En la tabla members del sistema se insertan las entradas del repositorio general de la escuela, introduciendo tanto alumnos como profesores que forman parte de la escuela. El sistema estará dividido en los siguientes foros: ➢ Titulaciones: diferentes carreras impartidas en la escuela. ➢ Departamentos: diferentes departamentos que componen la escuela. ➢ Organización: temas referidos a secretaria... ➢ Ayuda: soporte para el empleo de la plataforma.
Dentro de estos foros principales, se encuentran los subforos de nivel 1 (cuelgan directamente de los foros padres del sistema). Dentro de los subforos de nivel 1 se encuentran los subforos de nivel 2 y así sucesivamente. En el interior del foro principal Titulaciones, se han insertado los subforos de nivel 1 correspondientes a las diferentes carreras que se imparten en la escuela. Dentro de los subforos de nivel 1 de carreras se han insertado los subforos de nivel 2 correspondientes con las diferentes materias que se imparten en dichas titulaciones.
En cada subforo de nivel 2 correspondiente a materias, se han insertado los siguientes subforos de nivel 3: ➢ Objetivos: foro que contiene hilos correspondiente a la documentación que proporciona el profesorado y que supone los objetivos de dicha materia. ➢ Contenidos: foro donde el profesor inserta la documentación digital que compone el curso. ➢ Ejercicios: foro donde el profesor inserta propuestas y ejercicios para el alumnado. ➢ Evaluaciones: foro donde el profesor tiene la posibilidad de crear cuestionarios, exámenes, entrega de trabajos..., que pueden suponer un criterio para la evaluación de la materia. ➢ Tablón de información: foro donde el profesor y el alumnado ( por ejemplo el tutor, el delegado...) insertan información de interés. ( fecha de
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
exámenes, apuntes en copistería...). ➢ Foro de alumnos: foro donde los alumnos resuelven sus dudas sobre la materia con o sin el profesor.
Más adelante se pone un ejemplo de los diferentes hilos que pueden componer estos foros, como por ejemplo son: hilos normales, exámenes, entrega ftp... En el foro padre denominado Departamento, se insertan los subforos de nivel 1 correspondientes a cada departamento de la escuela. A su vez dentro de estos subforos, se introducen los subforos de nivel 2 correspondientes a los profesores que componen dicho departamento. Estos subforos de nivel 2 son el espacio privado que tienen los profesores. Los profesores se insertan en el sistema como usuarios administradores ( no superadministradores ) correspondientes al grupo que se ha creado a consciencia llamado PROFESORADO. Este grupo ha sido generado por el supersusuario en el momento de la configuración del sistema y se le ha otorgado todos los permisos de administración. En dicho espacio privado el profesor podrá crear subforos, colgar su C.V, contar su vida, colgar apuntes futuros, diapositivas.... limitando en cualquier caso el acceso o visibilidad a los alumnos. En el foro padre denominado Organización se crearán foros y contenidos relacionados con Secretaria, Administración... Se ha creado un grupo denominado ADMON, cuyos miembros son todas las personas que trabajan en cargos de administración y derivados dentro de la escuela. El grupo ADMON tiene todos los privilegios sobre el foro Organización, pero no sobre el foro Departamentos y Organización. Y lo mismo pasa con el grupo PROFESORADO, que tiene todos los privilegios sobre estos dos foros, pero no sobre el foro de Organización. En el foro Ayuda se crearán diferentes secciones que den soporte a profesores y alumnos a utilizar el sistema en sí, como pueden ser FAQ's (Frecuently Asked Questions), ayuda general para la escuela...
Todos los alumnos se ha insertado en el grupo REGISTERED que se ha dejado con los privilegios por defecto, además se ha deshabilitado la opción de darse de alta en el
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada sistema, puesto que esta función se realiza a través del grupo de Organización o Superusuario. A continuación se adjunta un esquema que describe la estructura básica del sistema, con entradas ejemplo.
Figura 21: Estructura básica del caso de uso
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
3.6.2 Funcionalidades
En este apartado se explican algunas de la funcionalidades que proporciona la plataforma Ninbox aplicadas al caso de uso que se explica en el punto anterior.
Los usuario, en este caso, alumnos, profesores y personal de administración de la Escuela Técnica Superior de Ingenieros de la Universidad de Sevilla deben iniciar sesión para comenzar a usar los servicios de la plataforma. El modo en que la plataforma autentica es mediante un sistema single-sign-on que ha sido desarrollado y cuya clase principal es CONTROL y que ya fue explicada en puntos anteriores. Una vez autenticado el usuario, se cargaran los privilegios del mismo y el sistema comprobará a que secciones o recursos tiene acceso.
Continuando con el caso de uso anterior, el profesor Antonio J. Sierra decide insertar el contenido de su asignatura Fundamentos de la Telemática. Para realizar esto creará en el subforo llamado Contenido dentro del foro con el mismo nombre que la asignatura, tantos hilos normales como temas ( por ejemplo ). Los hilos normales son básicamente entradas estándar de foros. Es decir, el profesor creará un nuevo hilo con un título concreto e introducirá el contenido mediante el editor WYSIWYG desarrollado en este proyecto. Además tendrá la posibilidad de insertar archivos asociados al hilo, es decir, mediante una herramienta de transferencia de archivos, cargará un archivo al servidor. Dado que el profesor es administrador, podrá configurar el sistema de tal manera que ningún miembro pueda crear más hilos o responder a los ya existentes en el foro Contenido.
Además, dicho profesor ha visto oportuno crear varios formularios para evaluar los conocimientos de los alumnos, y que éstos puedan comprobar si realmente se están preparando de manera adecuada la asignatura. Para este fin, creará un hilo tipo examen en el subforo Evaluación.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Este tipo de hilos, poseen un asistente para su creación. El asistente va guiando al profesor en todos los pasos para su correcta creación y configuración. Una vez, el profesor selecciona crear un nuevo hilo tipo examen, aparecen las siguientes opciones. Añadir pregunta: herramienta mediante la cual se accede al menú de creación de preguntas de examen. Menú de creación de preguntas de examen: interfaz para configurar el tipo de pregunta. Los tipos de pregunta son: tipo test ( multirespuesta ), de desarrollo, de entrega de trabajos... Si se crea una pregunta tipo test, se debe indicar si es multirespuesta o respuesta única, además se debe indicar la respuesta(s) correcta(s). En caso de crear una respuesta tipo desarrollo, el asistente solicita el número de caracteres máximo si procede. En caso de pregunta tipo entrega de trabajos, el asistente solicita el tipo de archivos permitidos en la transferencia y el tamaño máximo del archivo. Una vez se han añadido todas las preguntas se pasa al menú de configuración de examen. En este menú se configura si el alumno solo puede realizar una vez el examen, si tiene tiempo máximo para realizarlo, si es materia de evaluación, en tal caso se crea una entrada nueva en la tabla evaluation relacionada con la materia. Dicha tabla almacena todas las evaluaciones relacionadas con las diferentes materias. Además, se puede configurar el examen para que realice un seguimiento de asistencia, tiempo de acceso... , esta opción se puede aplicar a cualquier hilo del sistema y permite realizar un seguimiento del mismo.
Cuando un alumno, con permisos suficientes para entrar en este foro visualiza un hilo tipo examen, en caso de que sea tipo evaluación de conocimientos, es decir, sin tiempo, puede hacerlo tantas veces como quiera y no genera entrada de notas... dicho alumno visualiza en la pantalla un formulario con las preguntas que compone el examen. Por ejemplo, preguntas tipo test generados con elementos OPTIONS de HTML, o preguntas tipo desarrollo generadas con elementos TEXTAREAS de HTML ( con el editor WYSIWYG opcionalmente integrado) o bien preguntas de tipo entrega de trabajos, es decir
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada un elemento FILE EXPLORER que abre un explorador del PC del alumno para seleccionar un fichero y realizar una transferencia al servidor.
Otras de las posibilidades que ha contemplado el profesor que se ha empleado en este ejemplo es la creación de un aula digital el día antes del examen a las 18:00. Así el profesor ha creado en el hilo foro Evaluación un hilo de tipo webConference. Para crear este hilo el sistema proporciona también un asistente. Dicho asistente configura la fecha, hora, número máximo de miembros, moderador, visitantes, duración... Posteriormente, el profesor utiliza el sistema de mensajería interna para mandar un mensaje privado de difusión a todos los alumnos de la materia en cuestión. Los alumnos que tengan configurado la plataforma de tal manera que reciben un mail por cada mensaje privado enviado, recibirán el mail confirmándole la fecha y hora de la webConference.
En el asistente de creación de webConference se comprobará que dicha hora y fecha está libres, en caso contrario no se permitirá crear una nueva aula digital. Esto está programado de esta manera para evitar saturación en el servidor, puesto que la aplicación webConference consume cierto número de recursos. Llegado el día y la hora concretada, los alumnos accederán al hilo creado como webConference y se arrancará la aplicación desarrollada en este proyecto. Mediante el sistema de diapositivas el profesor podrá dar una pequeña clase virtual para resolver posibles dudas a los alumnos, y éstos podrá a la vez preguntarle cuestiones que no tengan claras. El siguiente esquema representa la estructura del foro de la asignatura Fundamentos de la Telemática.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Figura 22: Estrucutra básica de una asignatura
Aún queda un punto importante por determinar en la configuración del sistema respecto a los privilegios de los usuarios. A parte de los grupos básicos que el sistema crea y que se vieron en el punto 3.2.2.7, el administrador del sistema debe crear otros grupos relacionados con el sistema. Un profesor ( o profesores que impartan una asignatura..) cuando crea una entrada de foro para una asignatura, lo que realmente se realiza es la creación de un curso y no de un foro. Un foro en este sistema es simplemente un contenedor de otros foros o hilos. Un curso es un tipo de foro especial. Cuando se crea un curso automáticamente se crea un
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada grupo asociado a este curso. El grupo recoge a todos los alumnos del curso. Por este motivo habrá tantos grupos más como asignaturas ( o cursos ). A este grupo pertenecen todos los alumnos que estén matriculados en la asignatura en cuestión. Mediante esta técnica se proporciona un mecanismo para que sólo los alumnos de esa materia puedan tener acceso a los contenidos de la misma. Para mantener actualizado dicho sistema de grupos, se puede crear una aplicación que realice una lectura de la base de datos de la escuela y actualice los grupos a los que pertenece cada alumnos dependiendo de sus matriculas.
Se adjunta un esquema que intenta sintetizar una hipotética situación de grupos y privilegios para el ejemplo en el que se está trabajando en este capítulo. Se ha puesto como ejemplo el profesor antes mencionado y un hipotético alumno llamado Carlos Serrano que está matriculado en Fundamentos de Telemática y Campos Electromagnéticos.
Miembro: Antonio J. Sierra. Grupos a los que pertenece: REGISTERED, PROFESORADO, ANTONIOJ, FUNDTELEM+. El primero de los grupos hace referencia al grupo por defecto al que pertenece cualquier miembro registrado. El segundo de los grupos hace referencia al grupo de profesores el cual tiene privilegios de administración en algunas zonas de foro, como puede ser los departamentos, crear curso... El grupo ANTONIOJ hace referencia a su propio grupo para así tener protegido su espacio personal dentro del departamento. El grupo FUNDTELEM+, es opcional y se crea en el caso de que sobre el foro de la asignatura de Fundamentos de la Telemática sólo se desee que tengan permisos de administración algunos profesores.
Miembro: Carlos Serrano. Grupos a los que pertenece: REGISTERED, FUNDTELEM, CAMPOSELEC. Igual que antes el grupo REGISTERED es para usuarios registrados, el grupo
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
FUNDTELEM es el grupo al cual pertenece por estar matriculado en dicha asignatura. Gracias a que pertenece a dicho grupo puede tener acceso a los recursos de la materia del foro ( curso ). E igual pasa con el curso de CAMPOSELEC.
3.6.3 Conclusiones
Lo que se ha buscado con el diseño de esta plataforma y es la realización de una plataforma educativa que a la par de integrar las más novedosas técnicas de programación web incorpore un sistema seguro de autenticación y sobre todo de control de acceso. El sistema de privilegios, puede en un principio resultar algo complicado, pero nada más lejos de realidad. Es sistema puede hacerse lo sencillo que se desee o lo complicado que se considere. Es ahí donde reside la virtud de esta plataforma. En la libertad de configuración. Esta plataforma puede servir para crear un simple foro, en cuyo caso el sistema de grupos se resume a los grupos que el sistema trae por defecto, o bien puede servir para crear una plataforma educativa para más de 4000 alumnos como se ha visto en este punto. Este caso, el de la Escuela de Ingenieros, es obviamente una situación complicada, y es por este motivo por el cual el sistema de grupos y privilegios debe ser complicado, pero eso no conlleva a que sea complicada su configuración. El sistema hace el trabajo, no el administrador. En el mismo ejemplo que se ha propuesto en este punto, existen infinitas combinaciones de grupos y privilegios para realizar la misma plataforma. Y de nuevo es ahí donde reside la innovación de este sistema, cada administrador puede adecuar de la manera más óptima la plataforma a sus necesidades. La posibilidad de crear infinitos grupos para infinitos foros proporciona uno de los mecanismo más importantes que caracterizan a este sistema. Un grupo es una simple entrada en una tabla, no conlleva peso en disco y tampoco carga de procesamiento. Esta plataforma tiene como límite el que tenga el propio administrador. Añadiendo nuevas funcionalidades y servicios puede presentarse como una buena aplicación de sistemas e- Learning.
Carlos Serrano Sánchez Plataforma Ninbox: aplicación web para integración de servicios e-Learning Capítulo 3 Aplicación desarrollada
Carlos Serrano Sánchez