TRABAJO FIN DE GRADO Interoperabilidad entre plataformas ... · Para empezar, la idea de integrar...

Jorge Roldán López

Eloy Javier Mata Sotés y José Manuel Sota Eguizábal

Facultad de Ciencia y Tecnología

Grado en Ingeniería Informática

2015-2016

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Interoperabilidad entre plataformas usando LTI (LearningTools Interoperability)

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2016

publicaciones.unirioja.esE-mail: [email protected]

Interoperabilidad entre plataformas usando LTI (Learning ToolsInteroperability), trabajo fin de grado

de Jorge Roldán López, dirigido por Eloy Javier Mata Sotés y José Manuel Sota Eguizábal(publicado por la Universidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

Facultad de Ciencia y Tecnología

TRABAJO FIN DE GRADO

Grado en Ingeniería Informática

Interoperabilidad entre plataformas usando LTI

(Learning Tools Interoperability)

Alumno:

Jorge Roldán López

Tutores:

Eloy Javier Mata Sotés

José Manuel Sota Eguizabal

Logroño, junio 2016

Mi agradecimiento a mi familia y amigos.Así como al resto de compañeros y profesores

que me han acompañado estos cinco añosy me han permitido llegar hasta aquí.

Resumen

El objetivo de este trabajo ha sido documentar y crear un módulo que permita la interopera-

bilidad entre diferentes plataformas educativas. En nuestro caso hemos integrado la herramienta

Belenus, un desarrollo propio de la Universidad de La Rioja, con la plataforma Blackboard Learn,

ampliamente utilizada en el ámbito de la educación superior. La integración se ha implementado

siguiendo el protocolo LTI, lo que ha hecho que el paso de una a otra herramienta sea transparente

para alumnos y profesores.

En este trabajo, además de añadir el soporte para el protocolo LTI en Belenus, se han creado

varias herramientas que están ya listas para ser integradas en el campus virtual: un explorador de

archivos, un sistema de entrega de prácticas y un listado de páginas de usuarios. Además, gracias

al explorador de archivos los alumnos podrán modificar sus páginas de usuario y los profesores

recoger las prácticas. Por otro lado se ha creado una página adicional de configuración que,

mediante un asistente, genera archivos XML para facilitar la configuración de estos enlaces.

Abstract

The aim of this project has been documenting and creating a module which allows several

educative platforms to interoperate between them. In our case, we have integrated the tool

Belenus, an internal development of the University of La Rioja, into Blackboard Learn platform,

widely used in higher education. The integration has been done using LTI protocol, which makes

using both of them simultaneously transparent to students and instructors.

In this project, apart from adding LTI support to Belenus, we have created several tools ready

to be integrated, out of the box, in the virtual campus: a file explorer, a practice submitting

system and a user webpage list. Moreover, thanks to the file explorer, students will be able to

modify their own webpages and teachers will be able to pick up practices. Apart from this, we

have design an additional configuration webpage which, through an assistant, generates XML

files to facilitate the configuration of these links.

I

Índice general

Resumen I

Abstract I

1. Introducción 11.1. Motivaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3. Terminología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4. Belenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Análisis y diseño 52.1. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Análisis de requisitos funcionales . . . . . . . . . . . . . . . . . . . . 5

2.1.2. Análisis de requisitos no funcionales . . . . . . . . . . . . . . . . . . . 5

2.1.3. Análisis de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1. Hitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2. Cronograma y desglose de tareas . . . . . . . . . . . . . . . . . . . . . 11

2.4. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1. Diagramas de actividad . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.2. Diseño de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.3. Diseño de las páginas web . . . . . . . . . . . . . . . . . . . . . . . . 14

3. Protocolos usados 153.1. Learning Tools Interoperability (LTI) . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1. Introducción histórica . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2. Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3. Datos transmitidos en una petición básica . . . . . . . . . . . . . . . . 16

3.1.4. Descripción de los servicios que ofrece cada servidor . . . . . . . . . . 19

3.1.5. Consideraciones sobre la seguridad . . . . . . . . . . . . . . . . . . . 20

3.1.6. Particularidades de LTI en Blackboard . . . . . . . . . . . . . . . . . . 21

3.2. OAuth 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1. Introducción histórica . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2. Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3. Breve explicación del funcionamiento . . . . . . . . . . . . . . . . . . 23

3.2.4. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

III

IV Índice general

4. Implementación 274.1. Despliegue de Blackboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2. Despliegue de Belenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3. Autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4. Páginas web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.1. Implementación general de las páginas . . . . . . . . . . . . . . . . . 32

4.4.2. Accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.3. Diseño de las páginas web . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.4. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.5. Privacidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4.6. Eficiencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5. Seguimiento y control 435.1. Control del alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2. Control de la planificación temporal . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.1. Duración de las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.2. Plazos de las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.3. Hitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3. Otras gráficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Conclusiones 51

A. Reuniones de seguimiento y control 53

B. Configuración de Blackboard 57B.1. Configuración para administradores . . . . . . . . . . . . . . . . . . . . . . . 57

B.1.1. Creando enlaces LTI . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

B.2. Configuración para profesores . . . . . . . . . . . . . . . . . . . . . . . . . . 62

B.2.1. Insertando enlaces LTI ya creados . . . . . . . . . . . . . . . . . . . . 62

B.2.2. Activando la opción de crear enlaces LTI . . . . . . . . . . . . . . . . 62

B.2.3. Creando nuevos enlaces LTI . . . . . . . . . . . . . . . . . . . . . . . 63

C. Configuración del servidor Apache 65

Bibliografía 67

Capítulo 1

Introducción

1.1. MotivacionesEn la actualidad es frecuente que, en los entornos educativos, se haga uso de plataformas vir-

tuales que favorezcan la comunicación fuera del horario de clases entre alumnos y profesores. En

estas herramientas se puede subir contenido, enviar mensajes, realizar entregas de prácticas. . . lo

que facilita enormemente la interacción de profesores y alumnos gracias a la gran versatilidad

que aportan.

Sin ir más lejos, en la propia Universidad de La Rioja, en la que me encuentro, se hace

uso de tres de estas plataformas: Blackboard Learn, Moodle y un desarrollo propio llamado

Belenus. La elección de cada una de estas herramientas, o de otras con enfoques más generales,

queda en manos de cada profesor, siendo Blackboard Learn la elección más frecuente y que

podríamos llamar oficial. Sin embargo, es, precisamente, esta variedad la que, en vez de facilitar

la tarea de alumnos y profesores, puede dificultarla o hacerla más pesada. El simple hecho de no

tener centralizado el contenido virtual hace que se deba estar pendiente de las tres plataformas

simultáneamente.

Así, con el objetivo de paliar este problema de unificación, surge este Trabajo Fin de Grado.

1.2. ObjetivoEl objetivo principal que se persigue en este proyecto es la integración de la plataforma

Belenus, como un módulo más, dentro del aula virtual de Blackboard Learn.

La idea de incorporar y unificar estas herramientas orientadas a la enseñanza no es nueva.

De hecho, existe un protocolo llamado LTI (Learning Tools Interoperability por sus siglas en

inglés) que proporciona un estándar de comunicación entre estos sistemas. Es precisamente este

el camino que se va a seguir para conseguirlo. Blackboard Learn es un desarrollo de la compañía

Blackboard Inc. que ha colaborado en la definición de LTI y ya incorpora soporta para él. Así

que nuestro objetivo final es dotar de soporte a Belenus.

Destacar que, de lograrlo, no solo conseguiríamos integrar Belenus en Blackboard Learn,

sino en otras muchas plataformas educativas como la propia Moodle, gracias al uso de este

protocolo común a varios LMS (siglas de Learning Management System). LTI está integrado en

Moodle, Blackboard Learn 9, Desire2Learn, Canvas from Instructure. . .

1

2 Capítulo 1. Introducción

1.3. TerminologíaA lo largo de esta memoria se hará uso de cierta terminología que conviene tener en cuenta

desde el principio. Para empezar, la idea de integrar dos plataformas educativas lleva implícito

que se ejerzan dos roles. Estos los llamaremos1:

TP (Tool Provider por sus siglas en inglés): será la herramienta integrada, es decir, la que

ofrezca sus servicios a otro LMS. En nuestro caso, este rol lo tiene Belenus.

TC (Tool Consumer por sus siglas en inglés): será la herramienta que haga uso de la otra, es

decir la que la invoque y la integre. En nuestro caso, este rol lo ocupará Blackboard Learn.

1.4. BelenusBelenus fue desarrollado por el Departamento de Matemáticas y Computación de la Univer-

sidad de La Rioja en el curso 2002/2003 como alternativa a la plataforma WebCT que usaba la

propia universidad en aquellos momentos.

Figura 1.1: Página principal de Belenus.

1Notar que esta terminología no es exclusiva de este Trabajo Fin de Grado. De hecho, es la utilizada en la propia

especificación del protocolo LTI.

1.4. Belenus 3

En su desarrollo se buscó crear una plataforma sencilla que solo incluyese las herramientas

necesarias para la titulación de Ingeniería Técnica de Informática de Gestión (ITIG). En concreto,

la funcionalidad con la que se dotó a Belenus fue:

Envío de prácticas por parte de los alumnos.

Recepción de prácticas por parte de los profesores.

Alojamiento de una página web personal.

Directorio personal para cada usuario gestionado por FTP de 30 MB (actualmente ampliado

a 100 MB).

En la figura 1.1 podemos observar una captura de la web a día de hoy.

Gracias a este servicio se permitió que desde cualquier ordenador con acceso a Internet,

ya sea desde casa o desde la universidad, los alumnos pudiesen utilizar estos servicios. Esta

información se puede ver de forma más detallada en [8].

Capítulo 2

Análisis y diseño

2.1. Análisis de requisitosA raíz de la primera reunión con el cliente y de la especificación y posibilidades que nos

aporta el protocolo LTI, se ha obtenido una lista de los requisitos y datos que necesitaremos

desarrollar y manejar.

2.1.1. Análisis de requisitos funcionalesEl objetivo mínimo que nos ha impuesto el cliente es el de documentar el desarrollo y

funcionamiento de un módulo LTI para Belenus. No obstante, también sería interesante si se

llega a desarrollar este módulo.

A vista de lo que actualmente podemos hacer en Belenus (ver sección 1.4), las funcionales

que sería interesante permitir usar a los usuarios a través del aula virtual de Blackboard son:

1. Que los alumnos puedan enviar prácticas.2. Que los profesores sean capaces de recoger las prácticas.3. Que se puedan consultar las páginas personales.4. Que se puedan gestionar los archivos del directorio personal.

En la figura 2.1 se muestra esta misma información recogida de forma esquemática en un

diagrama de casos de uso.

Notar que en la figura 2.1 solo aparecen dos actores: alumno y profesor. El administrador,

que en Belenus lógicamente existe, queda excluido de nuestro diagrama de casos de uso pues

no presenta ninguna actividad relevante. De hecho, los administradores de Belenus no juegan

ningún papel en la plataforma Blackboard, luego no deberán hacer uso de este sistema. En el

caso de que quieran hacer pruebas siempre podrán usarla bajo uno de los roles ya existentes.

2.1.2. Análisis de requisitos no funcionalesAdemás de los requisitos funcionales, nuestro proyecto también presenta requisitos no

funcionales.

El primero de ellos surge por la propia naturaleza del servicio. La autenticación de los

usuarios debe ser segura. Es decir, debe hacerse de forma fiable utilizando cifrado. Además, si

5

6 Capítulo 2. Análisis y diseño

Figura 2.1: Diagrama de casos de uso.

alguien captura los paquetes de autenticación no le deberán servir para nada. Dicho de otra forma,Un ataque de réplica es

aquel en el cual se reenvían

paquetes válidos que han si-

do interceptados. El objeti-

vo es que el servidor los de

por buenos y obtener así ac-

ceso, por ejemplo. A lo lar-

go de la memoria veremos

qué hemos hecho para evi-

tarlos.

no se debe poder extraer información relevante (no deben ir en claro) y no deben ser vulnerables

a ataques de réplica (se puede leer la explicación de este ataque en una nota al margen).

Por otro lado, surgen una serie de requisitos debido a que debemos acomodarnos a una

plataforma ya existente, Belenus. Así, nuestro desarrollo debe hacerse empleando principalmente

PHP, HTML, CSS y JavaScript que son los lenguajes soportados por el servidor y los clientes.

Además, sería interesante seguir las guías de diseño y estilo de la Universidad y hacer uso, en

la medida de lo posible y adecuado, de las partes ya implementadas. Igualmente, tenemos que

ajustarnos a las limitaciones del servidor donde se alojará nuestro desarrollo (por ejemplo no

cuenta con un Sistema Gestor de Bases de Datos) y utiliza PHP en su versión 5, según se deduce

de sus archivos de configuración. También debemos acomodarnos a su estructura de carpetas y

archivos de configuración ya existentes.

Por último, debemos llevar a cabo un registro de las actividades anómalas como ya hace

Belenus, para que en caso de error podamos saber qué ha ocurrido.

2.1.3. Análisis de datosNuestro sistema debe identificar a los usuarios, luego al menos debe de contar con algún

método de autenticación y, por tanto, tener acceso a estos datos. Belenus hace uso de autenticación

mediante el protocolo LDAP. Los usuarios introducen el nombre de usuario de su CUASI (Cuenta

Única de Acceso a los Servicios Informáticos por sus siglas) y contraseña y estos se consultan

en una base de datos alojada en otro servidor. Por ahora este acceso se hace como hemos dicho

mediante LDAP, aunque la universidad se encuentra actualmente migrándolo poco a poco a

Microsoft Active Directory.

Sin embargo, la autenticación a través de LTI es completamente diferente. En la figura 2.2

podemos ver que en una petición de este tipo no se envía en ningún momento la contraseña de

la CUASI o una contraseña al uso. Incluso por defecto no se envía ningún nombre de usuario.

Esto se debe a que la autenticación se realiza mediante el protocolo OAuth. Este protocolo se

2.1. Análisis de requisitos 7

explicará con más detalle en la sección 3.2. Por ahora, lo único que debemos saber es que esto

nos obliga a almacenar pares identificador-secreto, compartidos por el TC y el TP.

Figura 2.2: Petición del TC al TP con los datos de autenticación.

Además, se necesitará almacenar algún dato más a parte de estos pares:

Los nonce (números de un solo uso, en la figura 2.2 aparecen como el parámetro

oauth_nonce) de las peticiones para evitar ataques de réplica. Estos se guardarán junto

al identificador del consumidor (oauth_consumer_key) y una fecha.

Posibles configuraciones del servicio a la hora de atender peticiones: puertos, servidores

por defecto, etc.

Una posible asignación del par TC-userID con el usuario real de Belenus.

Registro de actividad (log).

Lista de usuarios: alumnos y profesores.

Algunos de estos datos, como estos dos últimos, ya están almacenados en el servidor Belenus.

Es por esto, y debido a la simplicidad de los valores a almacenar (no hay apenas relaciones, son

datos de texto plano y de usarse tablas tendrían muy pocas columnas), que hemos optado por


utilizar ficheros de texto plano para almacenarlos. Este es de hecho el método que ya se utiliza en

Belenus. Utilizar un Sistema Gestor de Bases de Datos (SGBD por sus siglas) sería demasiado

potente para la tarea que nos ocupa y además no sabemos si el servidor Belenus lo soportaría,

pues actualmente no hace uso de ninguno de estos sistemas.

2.2. Alcance

Vamos ahora a definir el alcance del proyecto. Para ello nos apoyaremos en la descomposición

de tareas que se muestra en la figura 2.3.

Figura 2.3: Estructura de Descomposición de Tareas del proyecto.

Veamos ahora cuáles son estas tareas, describiendo en qué va a consistir cada una:

1.1.1 Planificación: Definición de las tareas, cronograma e hitos del proyecto. Además,

en esta parte, se incluirá dicho contenido a la memoria.

2.2. Alcance 9

1.1.2 Seguimiento y control: Control del desarrollo del proyecto contrastándolo con

lo planificado. Aquí se incluirían posibles replanificaciones en caso de que sea necesario.

Al finalizar se incluirá un informe en la memoria que detalle cómo ha sido la evolución

del proyecto.

1.1.3 Definición del alcance y requisitos: Se define el alcance del proyecto, así como

los requisitos que debe cumplir y se incluye en la memoria.

1.1.4 Reuniones: Reuniones de seguimiento y resolución de posibles dudas a lo largo

del proyecto. Se estima una media de una reunión cada dos semanas con una duración

aproximada de una hora cada una.

1.2.1 PHP: Incluye la instalación de un intérprete de PHP, así como hacerse con su

sintaxis básica y probar unos primeros ejemplos.

1.2.2 Protocolo LTI: Lectura y compresión de la documentación de LTI accesible

en [7]. También se redacta la parte de la memoria referente al funcionamiento y a las

posibilidades que nos aporta este protocolo.

1.2.3 Protocolo OAuth: Incluye la comprensión de las bases del protocolo OAuth, así

como una búsqueda y prueba de implementación con una biblioteca OAuth que podamos

luego usar para verificar las firmas digitales en nuestra aplicación.

1.2.4 Belenus: Comprensión del código que compone Belenus para entender cómo

funciona y cómo está estructurado. También se aprovecha este punto para desarrollar una

breve explicación en la memoria de este servicio. En esta tarea también se realizará el

despliegue del servicio.

1.2.5 Blackboard: Incluye la instalación y puesta en marcha de su máquina virtual, así

como dar de alta un primer enlace LTI para hacer pruebas preliminares. También incluye la

documentación de cómo se realiza este proceso. Asimismo, en este punto, se compararán

los resultados observados en las peticiones LTI de Blackboard con los descritos por el

protocolo LTI.

1.3.1 Análisis y diseño: En este fase se definirán las distintas partes que componen la

aplicación y se definirá en qué van a consistir y cómo se van a hacer.

1.3.2.1 Autenticación: Se desarrollará el módulo que verificará cada petición recibida,

comprobando su validez y que esté firmada correctamente.

1.3.2.2 Páginas web: Se crearán todas las páginas web que compondrán la aplicación y

a las que se les integrará el módulo desarrollado en la tarea 1.3.2.1.

1.3.3 Pruebas: En esta fase se verificará que la aplicación funciona correctamente y

no presenta problemas. Se llevarán a cabo pruebas de integración y de funcionamiento

general.

1.4.3 Documentación: Documentación del código generado, así como redacción de

algunas explicaciones en la memoria. Para ello se seguirá tanto el estilo que ya utiliza

Belenus, así como uno similar al empleado para generar JavaDocs.

1.4.1 Memoria: Redacción de la memoria, así como completar y unir las diferentes

partes que la componen dotándola de uniformidad.

1.4.2 Hacer presentación: Desarrollo de las diapositivas, así como del guión que se

empleará durante la defensa de este Trabajo Fin de Grado.


1.4.2 Ensayar: Se ensayará y memorizará la estructura de la presentación. Aquí

también se incluye la defensa del presente trabajo.

Notar que debido a que la memoria se va a desarrollar en LATEX, que es código fuente, se va a

utilizar Git (en concreto GitHub) durante todo el proyecto para llevar control de versiones tanto

de la memoria como de la implementación.

2.3. PlanificaciónLa realización del proyecto está repartida a lo largo de 300 horas divididas en 285 de trabajo

autónomo y 15 de seguimiento y control con el tutor asignado, en este caso, con los dos tutores.

Las mencionadas 300 horas de trabajo se distribuirán1como indica el cuadro 2.1.

Código Tarea Tiempo est. Inicio Fin

1.1.1 Planificación 15 horas Semana 5 Semana 6

1.1.2 Seguimiento y control 15 horas Semana 6 Semana 21

1.1.3 Alcance y requisitos 5 horas Semana 3 Semana 3

1.1.4 Reuniones 10 horas Semana 1 Semana 22

1.2.1 PHP 10 horas Semana 2 Semana 3

1.2.2 Protocolo LTI 20 horas Semana 3 Semana 4

1.2.3 Protocolo OAuth 15 horas Semana 4 Semana 6

1.2.4 Belenus 20 horas Semana 6 Semana 7

1.2.5 Blackboard 10 horas Semana 4 Semana 5

1.3.1 Análisis y diseño 30 horas Semana 7 Semana 10

1.3.2.1 Autenticación 20 horas Semana 10 Semana 12

1.3.2.2 Páginas web 50 horas Semana 12 Semana 15

1.3.3 Pruebas 20 horas Semana 11 Semana 16

1.3.4 Documentación 15 horas Semana 11 Semana 16

1.4.1 Memoria 30 horas Semana 2 Semana 20

1.4.2.1 Hacer presentación 10 horas Semana 20 Semana 22

1.4.2.2 Ensayar 5 horas Semana 22 Semana 23/24

1 TOTAL 300 horas Semana 1 Semana 23/24

Cuadro 2.1: Tiempo y periodo de ejecución de cada tarea.

2.3.1. HitosDurante el progreso del proyecto se definen los siguientes hitos:

Fin de la planificación – Semana 6 (7 - 13 marzo).

Fin de la formación – Semana 7 (14 - 20 marzo).

Fin del análisis y diseño – Semana 10 (4 - 10 abril).

1Como notación empleamos el número de semana, siendo semanas naturales empezando desde el 1 de febrero. Así,

por ejemplo, la semana 9 (del 28 de marzo al 3 de abril) es festiva, es Semana Santa.

2.3. Planificación 11

Fin de implementación – Semana 15 (9 - 15 mayo).

Fin de pruebas – Semana 16 (16 - 22 mayo).

Depósito del proyecto – Semana 21 (20 - 26 junio), en concreto del 22 al 24 de junio.

Defensa del proyecto – Semana 23/24 (4 - 17 julio), concretamente del 7 al 13 de julio.

Para comprender mejor cómo quedan distribuidos a lo largo del tiempo se incluye un

diagrama de hitos en las figuras 2.4 y 2.5.

Hitos/Semana 01 02 03 04 05 06 07 08 09 10 11 12

Fin de la planificación �Fin de la formación �Fin del análisis y diseño �

Fin de implementación

Fin de pruebas

Depósito del proyecto

Defensa del proyecto

Figura 2.4: Diagrama de hitos (parte 1/2).

Hitos/Semana 13 14 15 16 17 18 19 20 21 22 23 24

Fin de la planificación

Fin de la formación

Fin del análisis y diseño

Fin de implementación �Fin de pruebas �Depósito del proyecto �

Defensa del proyecto �

Figura 2.5: Diagrama de hitos (parte 2/2).

2.3.2. Cronograma y desglose de tareasPara concluir con la planificación se detalla un diagrama de Gantt (ver figuras 2.6 y 2.6)

donde se observa la distribución de las cargas de trabajo introducidas en la figura 2.3 a lo largo

del tiempo.

Como se puede intuir de las tareas y diagramas descritos, la metodología que se va a utilizar

para este desarrollo es similar a la tradicional en cascada. Aunque en nuestro caso cuenta con

ligeros solapamientos, sobre todo en implementación y pruebas. Estas se desarrollan a la vez

para detectar los errores cuanto antes y así evitar su efecto vaya creciendo con el desarrollo.

Se ha elegido esta metodología pues estamos ante un proyecto donde el cliente no necesita ir

viendo constantemente el progreso, ni estará introduciendo cambios. Además, en caso de elegir

una metodología ágil, hasta bien avanzado el proyecto no seríamos capaces de desarrollar un

prototipo debido a la parte de formación, perdiéndose una gran ventaja de estas metodologías.


Tareas/Semana 01 02 03 04 05 06 07 08 09 10 11 12

Planificación

Seguimiento

Alcance

Reuniones

PHP

Protocolo LTI

Protocolo OAuth

Belenus

Blackboard

Diseño

Autenticación

Páginas web

Pruebas

Documentación

Memoria

Presentación

Ensayar

Figura 2.6: Diagrama de Gantt (parte 1/2).

Tareas/Semana 13 14 15 16 17 18 19 20 21 22 23 24

Planificación

Seguimiento

Alcance

Reuniones

PHP

Protocolo LTI

Protocolo OAuth

Belenus

Blackboard

Diseño

Autenticación

Páginas web

Pruebas

Documentación

Memoria

Presentación

Ensayar

Figura 2.7: Diagrama de Gantt (parte 2/2).

2.4. Diseño 13

2.4. Diseño

2.4.1. Diagramas de actividad

Debido a la relevancia del caso de uso Autenticación, hemos decidido incluir un diagrama de

actividad en la figura 2.8 describiéndolo. Notar que el diagrama no presenta varias calles pues

todo él tiene lugar en el servidor.

Figura 2.8: Diagrama de actividad que describe el proceso de autenticación.

2.4.2. Diseño de las pruebas

A lo largo del desarrollo se irán realizando pruebas para garantizar la corrección de los

métodos y páginas. Para la parte de autenticación, las pruebas consistirán en modificar los

parámetros buscando recorrer los posibles caminos que recoge el diagrama de la figura 2.8.

Mientras que para las páginas web se llevarán a cabo pruebas alterando las peticiones HTTP.

Finalmente también se probará el funcionamiento en varios navegadores y sistemas operativos,

incluyendo dispositivos móviles.


2.4.3. Diseño de las páginas webComo ya habíamos comentado en la sección 2.1.2, las páginas que vamos a desarrollar deben

presentar un aspecto adaptado a las guías de diseño y estilo de la universidad. No obstante,

debido también al deseo de adaptarse a dispositivos móviles, las páginas van a seguir un estilo

más moderno, aunque conservando la paleta de colores y logotipos de la institución.

Las páginas en general presentarán tres zonas horizontales. Arriba tendremos la barra de

navegación, en la parte inferior el pie de página y en la zona central se encontrará el área principal:

páginas de usuarios o archivos. A continuación se pueden ver unos bocetos.

Atrás Arriba Nueva carpeta Subir archivo Descargar Eliminar

Figura 2.9: Diseño de la cabecera del explorador de archivos.

Acerca Belenus Departamento

Figura 2.10: Diseño del pie de página.

Profesor

AsignaturaSubir archivo

(a) Diseño de la cabecera para enviar prácticas.

AsignaturaDescargar

Alumno

(b) Diseño de la cabecera para recibir prácticas.

Figura 2.11: Bocetos generales de la cabeceras de prácticas.

Profesores Alumnos

Profe1 Alum1

Profe2 Alum2

Profe3 Alum3

Profe4 Alum4

Profe5 Alum5

Profe6 Alum6

Pie

Buscador y pasar de página

(a) Diseño general de la página donde se listan

las páginas de usuario.

Nombre archivo Detalles

File1 Det1

File2 Det2

File3 Det3

File4 Det4

File5 Det5

File6 Det6

Pie

Cabecera

(b) Diseño general de la página lista de archivos

y prácticas.

Figura 2.12: Bocetos generales de las páginas web.

Capítulo 3

Protocolos usados

En este capítulo vamos a explicar para qué sirven y en qué consisten los principales protocolos

de los que vamos a hacer uso. En concreto, vamos a explicar el protocolo LTI y el protocolo de

autenticación OAuth. Notemos que nuestra aplicación, como es natural, hace uso de muchos

otros protocolos como HTTP, TCP. . . aunque no vamos a profundizar en ninguno más.

3.1. Learning Tools Interoperability (LTI)El objetivo de este protocolo es especificar las herramientas y contextos que permitan la

integración de varios LMS (Learning Management System por sus siglas en inglés) o sistemas

de gestión de aprendizaje, en nuestro caso Blackboard y Belenus.

Un sistema de gestión de aprendizaje, según [14], es un software instalado en un servidor web

que se emplea para administrar, distribuir y controlar las actividades de formación no presencial

(o aprendizaje electrónico) de una institución u organización. Este permite un trabajo de forma

asíncrona entre los participantes. Las principales funciones de los sistemas de gestión de apren-

dizaje son: gestionar usuarios y recursos (materiales y actividades de formación), administrar el

acceso, controlar y hacer seguimiento del proceso de aprendizaje, realizar evaluaciones, generar

informes, gestionar servicios de comunicación como foros de discusión, videoconferencias,

entre otros.

3.1.1. Introducción histórica

LTI (siglas de Learning Tools Interoperability) fue desarrollado por IMS Global, un consorcio

de aprendizaje. La primera especificación, denominada 1.0, surgió en mayo 2010. Desde entonces

han ido saliendo distintas revisiones, siendo la última aquella lanzada el 5 de enero de 2015 bajo

el nombre de LTI v1.2. Podemos ver la cronología de las distintas versiones en la figura 3.1.

Sin embargo, cabe destacar que un año antes, en enero de 2014, la especificación de LTI 2.01

fue publicada. No obstante, nuestra implementación a lo largo de este proyecto va a ser de

la versión 1.2, pues es la máxima version que soporta a día de hoy la versión de Blackboard

utilizada por la universidad.

1Esta versión es compatible con las versiones 1.x y añade como nuevas funcionalidades una API Rest e intercambio

de datos mediante JSON.

15

16 Capítulo 3. Protocolos usados

LTI1.0

LTI1.1

LTI1.1.1

LTI2.0

LTI1.2

2010 2011 2012 2013 2014 2015 2016

Figura 3.1: Linea temporal de la evolución del protocolo LTI.

3.1.2. FundamentosAntes de entrar a explicar el funcionamiento del protocolo, vamos a entender algunos

conceptos que aparecen en él, a parte de los ya mencionados en la introducción: los roles TC y

TP. Por ejemplo, el término contexto. Un contexto es un conjunto de usuarios, roles y contenidos.

Es el caso de un grupo o curso donde se pueden agrupar varios enlaces LTI. Cada enlace dentro de

un curso compartirá atributo context_id y se distinguirá por su resource_link_id. Además,

cada petición irá firmada mediante el empleo del protocolo OAuth, que se explica brevemente en

la sección 3.2. Este protocolo requiere de una clave y un presecreto compartidos. Estos pueden

ser gestionados de tres formas distintas:

Credenciales comunes en el TC para todos los enlaces LTI que vayan a un mismo dominio.

Credenciales comunes en el TC para todos los enlaces LTI que vayan a la misma URL.

Credenciales propias para cada enlace LTI.

En las dos primeros opciones es el administrador del TC, Blackboard en nuestro caso, el

encargado de fijar estas credenciales. Mientras que, en la última, se deja que sean también los

instructores (profesores de un TC) quienes editen estos valores. En nuestra situación, debido a

que queremos que los profesores puedan especificar los parámetros a enviar, debemos emplear

credenciales a nivel de enlace. Esto es una limitación de Blackboard, que no tendría por qué

existir, al menos según la especificación de LTI, que podemos ver en [7].

3.1.3. Datos transmitidos en una petición básicaCuando se hace un lanzamiento LTI o petición a un TP se realiza una petición POST2 al

servidor enviándose una serie de datos. La mayor parte de estos pueden resultarnos superfluos o

servirnos únicamente para tareas de seguimiento y análisis. La tarea del TC debería ser mandar

tanta información como sea posible para maximizar las opciones de éxito con el TP. Mientras

que este último debe estar preparado para responder cuando no recibe toda la información que

necesita, o bien porque el TC no tiene la información, o bien porque ha sido configurado para no

compartirla.

Los parámetros o campos obligatorios que se envían en toda petición LTI, junto con ejemplos

de sus posibles valores, son:

lti_message_type=basic-lti-launch-request

Tipo de mensaje. Útil para diferenciar distintos tipos de peticiones a la misma URL. En

este proyecto no debemos preocuparnos de que tome otro valor.

2Notar que, como a priori un click en un enlace no realiza una petición POST, se necesita que el navegador soporte

JavaScript o que pase por un formulario intermedio (con campos hidden) y lo envíe.

3.1. Learning Tools Interoperability (LTI) 17

lti_version=LTI-1p0

Número de versión del protocolo LTI. Notar que como la versión 1.1 es totalmente

compatible en ambas direcciones con la 1.0, este valor es el mismo en ambas versiones.

resouce_link_id=88391-e1919-bb3456

Como habíamos adelantado identifica al enlace. Es un valor que cambia para cada coloca-

ción de este, es decir, si se exporta o se muestra en varios sitios distintos, este identificador

cambiará.

No obstante, existen infinidad de campos opcionales que nos recomiendan utilizar. Algunos

de los más interesantes, entre los que envía Blackboard, que hemos visto son:

Los que nos dan más información del enlace:

• resouce_link_title=Enviar prácticasTítulo con el que se muestra el enlace LTI al usuario.

• context_id=1234123-006f-27b2006ac545Un identificador opaco del contexto.

• context_tile=Trabajo Fin de GradoUn título para ese contexto, de longitud cercana a una línea.

• context-label=TFG2014Una etiqueta que hace referencia el contexto. Pensada para entrar en una columna.

• launch_presentation_document_target=frameNos indica el contenedor donde va a mostrarse el TP. Se puede ignorar o intentar

detectarse por JavaScript. Los posibles valores son: frame, iframe, window, popup,overlay y embed. Este último poco común. Significaría que es una petición entre

servidores y que primero el TC la va a procesar internamente.

• launch_presentation_css_url=<url>Un CSS para permitir que el TP adapte su apariencia para asemejarla a la del TP.

No obstante, no existen estándares sobre qué debe declarar esta hoja de estilos. En

nuestro caso al final hemos optado por no usarlo, pues, tras hacer pruebas, hemos

visto que apenas consigue lograr un aspecto uniforme entre ambas plataformas y no

es un estándar.

• launch_presentation_return_url=<url>Una URL donde se pueda redirigir al usuario cuando el TP termine o falle. Además,

a esta URL podemos añadirle tres parámetros en la query string: lti_errormsgque describa el posible error (debe ser comprensible por el usuario si se muestra) o

lti_msg o lti_log si termina correctamente. En cualquier caso, como los paráme-

tros se pasan por GET deben cumplir con las limitaciones de tamaño que nos impone

la URL en estas peticiones. Esta URL se emplea cuando se hace clic en el botón salir

de nuestra aplicación en Belenus, enviando el mensaje de que se ha cerrado sesión

exitosamente.

Aquellos que nos detallan más al cliente:

• user_id=0ae831b8-78fs9-18b2311ac545Identificador único del cliente en el TC. No debería revelar información que nos

permita identificar la identidad real del usuario. No obstante nos será muy útil en

caso de que no recibamos el nombre de usuario para identificar al visitante.


• roles=InstructorUna lista separada de comas de valores URN (ver [7, Appendix A]). De aquí nos

interesará saber por ejemplo si tiene el rol «Instructor» para saber si es o no un

profesor. Aunque no debemos olvidar que esto nos dice qué rol tiene ese usuario en

el TC, que suele coincidir con el del TP, pero no tiene necesariamente que ser así.

• lis_person_name_given=Jorgelis_person_name_family=Roldán

lis_person_name_full=Jorge Roldán

[email protected]

Información típica del usuario que realiza la petición.

Por último, hay otros que nos dan información acerca del TC:

• tool_consumer_info_product_family_code=Blackboard Learn• tool_consumer_info_version=9.1.201410.160373• tool_consumer_instance_guid=12ad7628fe72d7bca72

Identifica al TC. Si la clave es compartida se puede inferir esta información del

oauth_consumer_key. En caso de que cada enlace tenga su propia clave, este

será el identificador que nos permita distinguir una instalación de un TC. También

nos puede ser útil para distinguir instalaciones que usan la misma clave pero se

encuentran en varios servidores3. En cualquier caso, estos parámetros también van a

quedar fuera de nuestras comprobaciones.

• [email protected]ás, LTI nos permite enviar parámetros adicionales. Estos nos dejan elegir el par que

formará la clave y el valor. Tendrán la forma custom_clave=valor. Pese a tener libertad, los

caracteres escritos en la clave serán pasados a minúsculas y todo carácter distinto de una letra

será reemplazado por un guion bajo. Así, si ponemos como par adicional a enviar

Revision:Capitulo=1.2.56,

lo que se enviará realmente será

custom_revision_captitulo=1.2.56.

Es importante señalar que en estos parámetros personalizados, el TC nos puede permitir

usar variables que luego serán sustituidas por un valor. Esto nos aporta gran versatilidad y

cobrarán relevancia en nuestra aplicación. Por ejemplo, al poner Username=$User.usernamese enviará algo así como custom_username=joroldan. Cabe destacar que cada TC puede

definir unas variables distintas y, aunque existen algunas descritas por la especificación (ver [7,

Apéndice C]), todo TP debe estar preparado para recibir una variable no sustituida, es decir,

custom_username=$User.username o similar. Esto querrá decir que el TC no conoce dicha

variable y no ha podido sustituirla.

En nuestro caso, no vamos a emplear ninguna variable más allá de la ya mencionada en el

ejemplo, que nos dará el nombre de usuario con el que ha iniciado sesión en Blackboard, que

es afortunadamente el mismo que en Belenus. Esta será la técnica principal que usaremos para

identificar las visitas. Si nos encontramos con que no se ha recibido, o si no ha sido sustituída, la

3Es lo llamado «tenencia múltiple» (ver [13]).

3.1. Learning Tools Interoperability (LTI) 19

mejor opción es mostrar una pantalla de login en el primer acceso y luego registrar su user_id,asociado al usuario, para futuras visitas.

Además de los parámetros descritos, toda petición LTI lleva un conjunto de parámetros

adicionales que nos permiten verificar su autenticidad. Para hacerlo se firman las peticiones

mediante el protocolo OAuth, que se describe en la siguiente sección. Notar que las credenciales

que emplea OAuth deben ser conocidas por ambos servidores, el TC y el TP. El cómo debe

hacerse no queda establecido ni por LTI, ni por OAuth. Nosotros vamos a pasar estos valores de

forma manual a la hora de configurar ambos servidores.

Notar que, a parte del lanzamiento básico descrito, LTI soporta también el envío de peticiones

POST cuyo contenido no es de tipo x-www-formurlencoded sino application/xml. En estos

casos se sigue empleando OAuth, aunque su implementación es ligeramente distinta. No vamos

a entrar en describirla pues escapa de los objetivos de este proyecto. No obstante, se puede

consultar en [7, Sección 4.3] y [5].

Por último, vamos a hablar de un parámetro más que puede ser muy útil para una imple-

mentación de LTI. Se trata de lis_outcome_service_url=<url>. En este parámetro se envía

una URL donde el TP puede devolver calificaciones (entre 0,0 y 1,0) al TC. Gracias a este,

Belenus podría ser capaz de enviar calificaciones de prácticas por ejemplo. Sin embargo, dado

que Belenus no soporta este servicio de calificaciones, no vamos a hacer uso de este parámetro

pese a su interés.

3.1.4. Descripción de los servicios que ofrece cada servidorDescripción del TP

Un enlace básico a un TP no es sino un enlace LTI autocontenido. Aunque nosotros no vamos

a ir más allá de enlaces básicos para configurar la comunicación entre Blackboard y Belenus, no

conviene olvidar qué hay debajo. Los enlaces LTI son instancias de un recurso. Este recurso es

descrito de una forma similar a la siguiente:

<resource identifier="I_00010_R" type="imsbasiclti_xmlv1p0"><file href="I_00010_R/BasicLTI.xml"/>

</resource>

Donde ese atributo href de la etiqueta file hace referencia a un archivo XML que describe

la configuración de la comunicación del TC con el TP. El esquema que debe seguir dicho

documento está descrito en la especificación del protocolo LTI y se puede encontrar junto a

un ejemplo, como ya viene siendo habitual, en [7, Sección 5]. Dentro de este documento se

encuentran, entre otros, la descripción del servicio, la URL donde deben dirigirse las peticiones,

tanto de tipo HTTP como HTTPS, los iconos y los parámetros que necesita.

Una vez se tiene la referencia, cada instancia es un simple XML de la forma:

<item identifier="BasicLTI1" identifierref="I_00010_R"><title>Nuestro primer enlace LTI</title>

</item>

Estos archivos son almacenados por Blackboard. De hecho, si activamos la opción de que los

profesores puedan definir sus propios parámetros, como se puede ver en el anexo B, el propio


Blackboard nos permitirá importar un archivo XML de configuración como el de [7, Sección 5]

para definir los enlaces. Es precisamente este archivo XML el que va a generar nuestra aplicación

para facilitar la configuración de estos enlaces a los profesores.

Descripción del TC

A su vez, el TC también contiene un documento que lo describe. En este caso, es un

documento en formato JSON. Su uso es opcional y, para que sea compartido con el TP en

cada conexión, debemos pasarlo manualmente como un parámetro opcional haciendo uso de

la variable $ToolConsumerProfile.url. Esta URL debe contener una dirección de no más

de 1023 caracteres y debe especificar qué versión de LTI está usando, empleando para ello

un parámetro lti_version en la misma URL. Salvo que tengamos alguna razón de peso,

deberíamos llamar a este parámetro opcional tc_profile_url.

En principio, esta descripción no cambia. No obstante, el TC puede fecharla gracias a la

cabecera Expires de HTTP para que, una vez vencida, el TP vuelva a solicitarla en busca de

cambios.

Un ejemplo de un archivo JSON se encuentra en [7, Sección 7]. En este archivo se detalla el

TP (su nombre, descripción, versión, versión de LTI que soporta) y los servicios adicionales que

ofrece, si es que los hay.

3.1.5. Consideraciones sobre la seguridadPara el desarrollo de esta sección, nos hemos basado en [11]. En este documento, además de

consideraciones sobre seguridad, podemos encontrar una descripción de buenas prácticas a la

hora de implementar OAuth en nuestro servidor: uso de ciertos parámetros, comprobaciones,

gestión de usuarios, etc.

Antes de empezar debemos decir que la política de seguridad del TC es controlada tanto por

su administrador como por los profesores, pues en nuestro caso ambos pueden llegar a tratar con

claves y creación de enlaces LTI. Obviamente, también es importante que el desarrollador tenga

en cuenta estos aspectos.

Por ejemplo, uno de los aspectos que se deben tener en cuenta es que el identificador de cada

clave, consumer_key, sea único. En este caso, la generación de estos identificadores y claves,

así como su distribución, no es tarea de este trabajo y es algo que se deja a los administradores

de Belenus. Otro aspecto importante es que el secreto sea suficientemente largo y se comparta de

forma segura para evitar ser descubierto. Además, la marca de tiempo de la petición recibida

debe ser comprobada como se explicará en la sección de OAuth para evitar ataques de réplica.

Destacar que gracias al uso de OAuth, si todo lo anterior se cumple, tendremos garantías que la

petición mantiene su integridad, es decir, no ha sido manipulada. Además, con el uso adicional

de HTTPS se puede garantizar que además no viajará en claro (no se podrá conocer su contenido)

y el servidor de destino quedará autenticado ante el cliente por su certificado.

Un aspecto que también nos va a afectar directamente es la confianza que podemos tener

en un usuario. En nuestra aplicación pedimos que se nos envíe el nombre de usuario en las

peticiones OAuth, que debemos confiar en que sea válido. Pero además, como este parámetro

es opcional, también tenemos un método alternativo que es pedirle iniciar sesión y registrar su

identificador de usuario. ¿Pero cómo de único es ese identificador? En principio, lo único que se

nos garantiza en la especificación de LTI es que es único en la plataforma en ese momento, no

3.2. OAuth 1.0 21

que no vaya a ser reutilizado. En principio, debido a que la limpieza de usuarios en Blackboard

se hace a lo sumo una vez al año, como en Belenus, no debería preocuparnos. Solo deberemos

tener en cuenta que el archivo que asocia identificadores a usuarios debe ser limpiado con cierta

periodicidad.

Antes de terminar vamos a comentar algunos problemas relaciones con medidas de seguridad

del navegador. Una que nos podría dar problemas a la hora de implementar LTI es mantener la

sesión en el TP con cookies. En principio, el TP puede estar en otro dominio y si se incrusta

como un iframe en el TC y el usuario bloquea las cookies de terceros no sería posible su

funcionamiento. En nuestra situación, como ambos, Belenus y Blackboard, están alojados dentro

del dominio unirioja.es, no tenemos dicho problema. No obstante, la solución es tan sencilla

como pedirle que se abra en una nueva pestaña. Incluso el propio TP con JavaScript podría

abrirse en una nueva pestaña/ventana.

Finalmente, decir que un problema intrínseco4 de OAuth es que los secretos deben guardarse

en claro5 en el servidor, pues no podemos almacenar un hash o resumen como viene siendo

habitual. Esto se debe a que necesitamos acceso a su valor para comprobar las firmas.

3.1.6. Particularidades de LTI en BlackboardA parte de la configuración que es propia en cada sistema6 y la limitación ya citada sobre

las credenciales que deben ser a nivel de enlace para permitir parámetros personalizados (ver

subsección 3.1.2), la principal característica que debemos tener en cuenta a la hora de utilizar

Blackboard como TC en el protocolo LTI es el envío de parámetros personalizados.

Las llamadas template varibales de Blackboard difieren de las propias del estándar que

habíamos visto en 3.1.3. Como se puede ver en [2] su sintaxis es completamente distinta. Por

ejemplo, la variable que representa el nombre de usuario (necesario en principio para identificar

al usuario que hace la petición) en lugar de obtenerse con la cadena $User.username debemos

usar @[email protected]@X@. A parte de estas, pocas particularidades más merece la pena destacar.

3.2. OAuth 1.0Como ya hemos dicho en la sección 3.1 la autenticación entre los

TC y TP cuando se comunican con el protocolo LTI se hace mediante

OAuth 1.0. Este protocolo es un mecanismo de seguridad diseñado

para proteger peticiones HTTP.

3.2.1. Introducción históricaOAuth nació en noviembre de 2006 cuando Blaine Cook estaba desarrollando la imple-

mentación de Twitter OpenID. Mientras, la empresa Ma.gnolia necesitaba un mecanismo que

permitiese usar widgets en el dashboard a los usuarios que se identificasen por OpenID. Así,

Cook, Chris Messina y Larry Haldd de Ma.gnolia se reunieron con David Recordon para discutir

el uso de OpenID como método de autenticación en las API de Twitter y Ma.gnolia. Concluyeron

que no había estándares abiertos para delegar la API de acceso y nació OAuth.

4La propia especificación de OAuth así lo recoge en sus últimos apartados sobre seguridad. Ver [5, Apartado 4.5].5O guardarse cifrados y en claro su clave de cifrado, que viene a ser similar.6La propia de Blackboard se describe en el apéndice B.


El grupo de discusión de OAuth fue creado en abril de 2007 con el objetivo de escribir un

borrador para el protocolo abierto en el que estaban trabajando. Empleados de Google, como

DeWitt Clinton, pronto se interesaron en el proyecto OAuth y comenzaron a colaborar. En julio

de 2007 el equipo publicó un primer borrador. Más adelante, Eran Hammer se unió y se encargó

de coordinar las distintas contribuciones al proyecto OAuth, formalizando así la especificación.

El 4 de diciembre de 2007 el borrador final del núcleo de OAuth 1.0 fue publicado.

En la LXXIII reunión del IETF (Internet Engineering Task Force) en Minneapolis, que

celebrada en noviembre de 2008, se hizo una primera reunión para discutir la estandarización de

OAuth, despertando mucho interés. Finalmente, en abril de 2010, el protocolo OAuth 1.0 fue

publicado como el RFC 5859.

Desde el 31 de agosto de 2010 todas las aplicaciones de terceros que utilicen la API de

Twitter deben usarlo.

El framework de OAuth 2.0, que no es compatible con la especificación de la primera versión,

fue publicado bajo los RFC 6749 y 6750 en octubre de 2012. Debido a que esta versión no es

un protocolo al uso, sus implementaciones son menos interoperables entre sí. Además, es una

versión que no vamos a tratar a no ser utilizada por LTI.

3.2.2. FundamentosEl fundamento básico de OAuth es autenticarse sin hacer uso de los clásicos usuarios y

contraseñas. En su lugar hace uso de secretos compartidos por ambas partes.

Al hacer una petición, se envían, a parte de los parámetros que sean necesarios en ese

momento, algunos específicos de OAuth que permiten la autenticación. Estos se identifican

porque comienzan por «oauth_». Algunos son:

oauth_consumer_key = <valor>

Es la clave que identifica al cliente, gracias a la cual el servidor puede conocer el secreto

que tiene asociado.

oauth_signature

Es la firma que se debe verificar. Se explica cómo se consigue más detenidamente en la

sección 3.2.3. Simplificando, es un hash o resumen criptográfico de la petición cifrado

con el oauth_consumer_secret asociado al oauth_consumer_key.

oauth_signature_method = <valor>

Es el método empleado para generar el valor del atributo oauth_signature. Puede tomar

tres valores:

1. HMAC-SHA1

2. RSA-SHA1

3. PLAINTEXT

oauth_timestamp = <valor>

Es una marca de la fecha de la petición expresada en segundos desde el tiempo UNIX o

tiempo POSIX (medianoche del 1 de enero de 1970 en horario UTC). Su uso es evitar

tener que almacenar indefinidamente los valores de oauth_nonce. Es importante que,

para que podamos usar este valor, los relojes de ambos servidores estén sincronizados o su

valor difiera muy poco (para LTI, según [7], se recomiendan 90 minutos de margen).

3.2. OAuth 1.0 23

oauth_nonce = <valor>

Es un identificador único de la petición que busca evitar ataques de réplica7. Para evitar

tener que almacenar estos valores indefinidamente se recomienda almacenarlos un tiempo

breve y, en caso de que el oauth_timestamp difiera por encima de este valor, rechazar la

petición al no poder comprobar si es válida o no.

oauth_version = <valor>

Identifica la versión del protocolo que se ha empleado. Para este proyecto su valor será

siempre 1.0.

3.2.3. Breve explicación del funcionamientoAhora vamos a explicar brevemente cómo, según se especifica en [5], el cliente realiza una

petición y el servidor la comprueba. Para ilustrar el funcionamiento vamos a usar la siguiente

petición a modo de ejemplo:

POST /carpeta/index.html?zoom=15%25 HTTP/1.1Host: localhost:8080Content-type: x-www-form-urlencoded

oauth_consumer_key=9djdj82h48djs9d2&oauth_token=kkk9d7dh3k39sjv7& �oauth_signature_method=HMAC-SHA1&oauth_timestamp=137131201&oa �uth_nonce=7d8f3e4a&oauth_signature=bYT5CMsGcbgUdFHObYMEfcx6bs �\&email=joroldan%40unirioja.es&name=Jorge+Rold%E1n

↪→

↪→

↪→

Código 1: Ejemplo de petición OAuth.

Como ya hemos dicho al explicar oauth_signature en el punto 3.2.2, la firma es apli-

car un algoritmo sobre una cadena base. La forma que tendrá la cadena a «cifrar»8 será:

<método>&<url>&<parámetros>.

1. El <método>, se toma de la petición directamente: GET, POST, PUT. . . En LTI es POST.

2. La <url> es la concatenación del valor de la cabecera Host junto a la ruta a la que va

dirigida la petición (la que aparece en la primera línea de esta, pero sin parámetros). Todo

ello va también precedido por el protocolo: http o https en nuestro caso. Así, a nosotros

nos queda: http://localhost:8080/carpeta/index.html.

3. Por último van los parámetros si hubiese, excluyendo oauth_signature, que aparecen:

a) Como query string en URL de la petición, es decir, aquellos que aparecen tras el

símbolo «?». En nuestro ejemplo, solo tenemos el parámetro «zoom».

b) El contenido de la cabecera HTTP «Authorization». Esta cabecera no aparece

en nuestro ejemplo, ni tampoco hará uso de ella Blackboard, así que no vamos a

profundizar en su estructura. No obstante, como el resto de la especificación, es

accesible en [5], más concretamente en [5, Sección 3.5.1].

7Este tipo de ataques consisten en reenviar una petición válida que hemos capturado para obtener acceso. Si está bien

implementada la autenticación debería ser capaz de detectar que esa petición ya ha sido atendida y por tanto desecharla.8Usando el método PLAINTEXT no se cifra.


c) En el cuerpo de la petición, pero solo si cumple todas y cada una de las siguientes

características:

El cuerpo solo tiene una parte, es decir, no viene en formato multipart.El cuerpo de la petición sigue los requisitos específicos definidos para la codifi-

cación «application/x-www-form-urlencoded».

En la petición aparece la cabecera «Content-Type» y esta toma el valor

«application/x-www-form-urlencoded».

Pero incluir estos parámetros tiene también su norma. Lo primero es decodificarlos para

obtener sus nombres y valores reales, es decir, independientes de la codificación que se

emplea en el envío. Recogemos estos valores en el cuadro 3.1.

Nombre Valor

zoom 15 %

oauth_consumer_key 9djdj82h48djs9d2

oauth_token kkk9d7dh3k39sjv7

oauth_signature_method HMAC-SHA1

oauth_timestamp 137131201

oauth_nonce d8f3e4a

email [email protected]

name Jorge Roldán

Cuadro 3.1: Primer paso en la obtenición de los parámetros.

El siguiente paso es codificar sus nombres y valores. Esto se hace haciendo uso de la

codificación UTF-8 y escapando los valores que no sean ni alfanuméricos ni ‘-’, ‘.’, ‘_’,

‘∼’ con un porcentaje seguido de su valor hexadecimal. Así obtenemos los valores que se

ven en el cuadro 3.2.

Nombre Valor

zoom 15 %25

oauth_consumer_key 9djdj82h48djs9d2

oauth_token kkk9d7dh3k39sjv7

oauth_signature_method HMAC-SHA1

oauth_timestamp 137131201

oauth_nonce d8f3e4a

email joroldan %40unirioja.es

name Jorge %20Rold %C3 %A1n

Cuadro 3.2: Recodificamos los parámetros leídos.

Una vez los tenemos codificados, los vamos concatenando como si de una query stringse tratase, pero siguiendo el orden alfabético que determina su valor en bytes. En nuestro

caso la cadena nos quedaría:

email=joroldan%40unirioja.es&name=Jorge%20Rold%C3%A1n&oauth_consum �er_key=9djdj82h48djs9d2&oauth_nonce=d8f3e4a&oauth_signature_me �thod=HMAC-SHA1&oauth_timestamp=137131201&oauth_token=kkk9d7dh3 �k39sjv7&zoom=15%25

↪→

↪→

↪→

3.2. OAuth 1.0 25

Cuando ya tenemos las tres partes que componen la cadena a cifrar, pasamos a codificar cada

una ellas como ya hicimos para calcular el cuadro 3.2. Después las concatenamos intercalando

el símbolo ‘&’. Finalmente, la cadena resultante nos queda como se ve en el código 2.

POST&http%3A%2F%2Flocalhost%3A8080%2Fcarpeta%2Findex.html&email%3 �Djoroldan%2540unirioja.es&name%3DJorge%2520Rold%25C3%25A1n&oa �uth_consumer_key%3D9djdj82h48djs9d2&oauth_nonce%3Dd8f3e4a&oau �th_signature_method%3DHMAC-SHA1&oauth_timestamp%3D137131201&o �auth_token%3Dkkk9d7dh3k39sjv7&zoom%3D15%2525

↪→

↪→

↪→

↪→

Código 2: Cadena resultante a firmar.

Esta cadena concatenada a un «&» y al «secreto del token», que es vacío9 en nuestro caso, se

cifra usando el método especificado en oauth_signature_method y se pone en la cabecera

oauth_signature.

Para verificar la firma solo debe repetir el proceso en el servidor y comprobar si el valor

recibido en oauth_signature coincide con el valor calculado.

3.2.4. ImplementaciónPara implementar OAuth se recomienda utilizar una biblioteca que nos abstraiga del engorro

de esta verificación. Para este proyecto hemos optado por hacer uso de la biblioteca «OAuth

Consumer And Server Library For PHP» que se encuentra disponible con la licencia del MIT en

https://code.google.com/archive/p/oauth-php/.

9Esto forma parte de usos más avanzados de OAuth que quedan fuera de nuestra especificación. En nuestro proyecto

como hacemos uso de OAuth para únicamente iniciar sesión, no necesitamos usar tokens en OAuth. Si se desean ver

vienen documentados en su espeficiación.

Capítulo 4

Implementación

La implementación de este proyecto, como se puede ver en la planificación (ver sección 2.3),

se divide en dos grandes bloques:

1. Autenticación: en este parte nos encargamos de comprobar las peticiones recibidas para

dar acceso a los servicios de Belenus.

2. Páginas web: en esta segunda parte se desarrollan todas las páginas web que componen

este proyecto.

4.1. Despliegue de BlackboardLa puesta en marcha de nuestra copia de Blackboard no ha generado ningún problema que

merezca la pena señalar. Simplemente hemos instalado la máquina virtual de desarrollo que se

nos ha proporcionado haciendo uso de Vagrant y VirtualBox y hemos accedido a ella vía SSH

para arrancar el servidor web. La única configuración especial que hemos tenido que hacer ha

sido ajustar la memoria RAM que se asigna a la máquina virtual. Por defecto, el archivo de

configuración de Vagrant que proporciona Blackboard asignaba 8 GB y hemos reducido esto a

1,5 GB. El rendimiento para nuestros propósitos es aceptable.

4.2. Despliegue de BelenusAntes de comenzar el desarrollo de cualquiera de los bloques, hemos de desplegar el servicio

Belenus tal y como funciona actualmente (páginas, estructura de las URL. . . ). Antes, ha sido

imprescindible estudiar todo su código y funcionamiento (ver tarea 1.2.4) para entender qué

íbamos a necesitar.

Para poner en funcionamiento Belenus hemos usado el mismo servidor bajo el que ya

funciona, Apache. Las diferencias con respecto al funcionamiento original son mínimas, solo

cambiamos el sistema operativo sobre el que corre, que en nuestro caso es OS X, y la estructura

de directorios ligeramente. Gracias a esto, tenemos que hacer cambios mínimos a los archivos de

configuración de Belenus que recibimos del servicio informático. En cuanto a PHP, optamos por

emplear la versión 5.6.19 funcionando en modo desarrollador para que nos imprima cualquier

warning y de esta forma podamos detectar errores más fácilmente.

27

28 Capítulo 4. Implementación

Al poner en marcha el servidor nos percatamos del primer gran problema: el sistema de

autenticación no funciona. Es decir, al introducir un nombre de usuario y contraseña no es

capaz de validarlos. Internamente, el funcionamiento de este servicio se hace mediante una

petición LDAP a un servidor de la Universidad de La Rioja. Pero, por algún motivo, las mismas

peticiones que Belenus puede hacer, a nosotros nos son rechazadas. Comprobamos si se debe a

que estamos accediendo desde el exterior de la red, pero ni desde dentro de la red de área local

de la universidad la petición es respondida.

Finalmente decidimos emular este comportamiento montando nuestro propio servidor LDAP.

Al fin y al cabo, de usar el correcto solo íbamos a poder utilizar un usuario, salvo que alguien se

ofrezca a aportar su CUASI para pruebas.

Montando nuestro servidor LDAP

En nuestro despliegue el servidor LDAP va a ser OpenLDAP, que es un servidor ampliamente

utilizado y de código abierto. A priori este puede ser distinto del empleado por la universidad,

pero gracias a que ambos hacen uso del protocolo estándar LDAP esto no debería suponer ningún

problema.

Inicialmente opté por montar OpenLDAP sobre mi propio sistema operativo OS X. Pero,

tras varios intentos fallidos y encontrarme conflictos con una instalación de OpenLDAP que, al

parecer, viene instalada por defecto con este sistema operativo, decido migrar el servidor LDAP

a la máquina virtual que aloja mi copia de Blackboard. Esta máquina virtual de desarrollo hace

uso del sistema CentOS.

La instalación y puesta en marcha del servicio fue algo complicada. La primera gran dificultad

es que nos enteramos que recientemente OpenLDAP ha migrado su configuración de un archivo

a una estructura de carpetas y casi todas las guías y referencias de Internet hacen uso del

método antiguo. Por suerte conseguimos hacernos con un asistente que nos permite migrar la

configuración realizada según el método antiguo al nuevo sistema. Otro de los problemas que

nos encontramos son los relativos a la comunicación: reglas en los firewall, que nos impedían la

comunicación tanto en OS X como CentOS, y asignación de puertos mediante NAT. Por último

debemos deducir a partir del código de Belenus los grupos y dominios que debemos dar de alta

en nuestro servidor LDAP para que las consultas funcionen.

Al final conseguimos que el servicio atienda las peticiones correctamente. Belenus ya corre

funcionando al completo sobre nuestra máquina.

4.3. AutenticaciónEste es quizá el punto más crítico del desarrollo, pues es la base de toda la seguridad del

sistema. La idea del protocolo LTI no es ofrecer un simple enlace en el aula virtual a Belenus,

sino que se ofrezca una forma de acceso desde dentro de Blackboard a Belenus sin necesidad de

pasar por ninguna autenticación extra. Es decir, con la petición POST que recibamos utilizando

el protocolo LTI, debemos ser capaces de conocer al usuario y ver si es una petición válida o no.

Como ya hemos visto al explicar el protocolo LTI, la comprobación de la validez de las

peticiones reside en el protocolo OAuth, que es el utilizado para firmar las peticiones. Dado que

este es un protocolo ampliamente conocido existen implementaciones. En nuestro desarrollo

vamos a hacer uso de la biblioteca OAuth Consumer And Server Library For PHP alojada bajo

una licencia libre en https://code.google.com/archive/p/oauth-php/.

4.3. Autenticación 29

Esta biblioteca tiene un funcionamiento relativamente sencillo de entender. Lo que hace es

delegar toda la parte de obtención de claves y almacenamiento de nonces, entre otras cosas, a

una capa de persistencia. Esta capa es seleccionada al invocar la biblioteca, usando MySQL por

defecto. Aunque también incorpora muchas más implementaciones que emplean otros gestores

de bases de datos, el scope de la sesión del servidor, etc. Para el caso que nos ocupa, lo que

debemos hacer es reproducir la interfaz de la capa de persistencia. Tenemos que implementar

la misma funcionalidad pero haciendo uso de ficheros de texto plano, en lugar de bases de

datos. Dado que todas hacen uso de la nomenclatura «OAuthStore*», vamos a denominarla

«OAuthStoreBelenus».

Esta capa de persistencia posee multitud de métodos, pero nuestro desarrollo va a ser

relativamente sencillo (dentro de la potencia de OAuth) y solo va a necesitar unos pocos. En el

resto de métodos que no vamos a necesitar vamos a dejar algo como lo que se ve en el fragmento

de código 3.

public function getServerForUri ( $uri, $user_id ) {throw new OAuthException2("OAuthStoreBelenus doesn’t support" . __METHOD__);↪→

}

Código 3: Método sin implementación en nuestra capa de persistencia

En concreto los cuatro métodos que implementamos son:

__construct($options = array())

El método constructor de nuestra persistencia. Este método puede recibir de forma opcional

un vector con parámetros de configuración. En nuestro caso aceptamos tres parámetros, el

fichero donde tenemos los secretos guardados, el fichero donde guardamos los nonces y,

por último, el tiempo máximo que puede diferir una marca de tiempo para que siga siendo

válida. Por defecto fijamos estos parámetros a dos archivos de la carpeta «config» y a 90

minutos1.

checkServerNonce($consumer_key, $token, $timestamp, $nonce)

Dado un consumer_key, token, timestamp y un nonce verifica si esa secuencia ya se

ha dado y la registra para evitar darla por válida en un futuro. Debido a que la capacidad

de almacenamiento es finita y no queremos que este registro crezca demasiado, nos hemos

creado un método auxiliar que limpia las entradas más antiguas.

cleanOlderTimestampsThan($time)

Este método privado no forma parte de la interfaz de la capa de persistencia. Es un método

auxiliar que borra los timestamp anteriores a una fecha dada.

getSecretsForVerify($consumer_key, $token, $token_type)

Obtiene la clave de cifrado dado un secreto. En realidad, dados tres parámetros debe

devolver un array de otros tres parámetros. De nuevo, debido a la simplicidad de nuestra

implementación, simplemente hacemos uso del primero, poniendo el resto a null. Se puede

ver el código en cuestión en el fragmento de código 4.

1Tiempo recomendado para LTI como habíamos comentado en el punto 3.2.2.


public function getSecretsForVerify ( $consumer_key, $token,$token_type = ’access’ ) {↪→

$secrets = parse_ini_file($this->secretsFile);if($secrets != false && isset($secrets[$consumer_key])) {

$secret = $secrets[$consumer_key];}else $secret = null;

return array("consumer_secret" => $secret,"token_secret" => null, "osr_id" => null);

}

Código 4: Método de nuestra capa de persistencia

Una vez creada la capa de persistencia debemos cambiar la clase «OAuthRequestVerifier»

para que que haga uso de ella. Para ello añadimos la línea:

$this->store = OAuthStore::instance(’Belenus’);

Con esto la biblioteca ya es completamente funcional. Ya solo nos queda ponerla en marcha.

Para hacerlo hemos creado la clase «BelenusValidator». Esta clase va a contener todos los

métodos propios de Belenus: obtención de usuarios, comprobación de contraseñas, verificar

peticiones. . . Esta ha sido la única parte que reutiliza un poco de código ya existente en Belenus,

pues el resto de partes cambian demasiado como para usarse. La llamada a la biblioteca que

verifica una petición OAuth se hace, entre otras cosas, en el método autenticarOAuth. En 5 se

ve el fragmento correspondiente a la llamada a este método.

$oAuthRequest = new OAuthRequestVerifier();if (OAuthRequestVerifier::requestIsSigned()) {

return $oAuthRequest->verifyExtended(false);}

Código 5: Fragmento de código que llama a la biblioteca

Destacar que esta misma clase es la encargada de una de las partes más vitales de toda la

implementación: el método autenticar. A la hora de desarrollar este método hemos tenido en

cuenta una importante consideración: el nombre de usuario es un parámetro extra del protocolo

y puede que no siempre lo recibamos. La solución tomada es la ya descrita en el diagrama de

actividad de la figura 2.8.

Conviene resaltar tres particularidades que nos hemos encontrado desarrollando la parte de

la autenticación:

1. Seguridad: a lo largo de esta parte hemos usado ciertos comandos de terminal que nos

facilitan la tarea, por ejemplo la búsqueda en ficheros mediante el comando grep. El

problema es que esta ejecución entraña riesgos. Es por ello que, en todo momento, se tiene

en cuenta el valor que puede tener cada parámetros para escaparlo y evitar la ejecución de

comandos indeseados. Para ello se hace uso de la función escapeshellarg y se recoge

en todo momento el código de respuesta del comando para saber si algo no ha salido como

estaba previsto.

4.4. Páginas web 31

2. Registro de eventos en el log: Como ya viene siendo habitual en el funcionamiento de

Belenus, los comportamientos anómalos: fallos en el login, parámetros incorrectos, etc.

son apuntados en un log. Siguiendo este funcionamiento, esta clase, así como algunas de

las pertenecientes a las páginas web, realiza este registro de actividad para que, si pasa

algo, se pueda tratar de averiguar qué ha ido mal.

3. Codificación: En Belenus la codificación por defecto es ISO-8859-1. Sin embargo, por

compatibilidad y debido a algunas limitaciones de las técnicas empleadas2, hemos decidido

dar el salto a la codificación UTF-8. Pese a que a priori es algo ventajoso, hemos tenido

que tener cuidado al leer y/o escribir ficheros que empleaba ya Belenus, pues siguen en la

codificación antigua por el momento. Para la conversión se ha tenido que hacer uso de los

métodos utf8_encode y utf8_decode que pasan de una codificación a otra.

4.3.1. PruebasEsta parte se ha llevado las principales pruebas del sistema debido a la naturaleza de los

métodos (breves y encargados de funcionalidades concretas). Se han llevado a cabo pruebas de

los métodos, primero invocándolos directamente y luego con todo el sistema ya montado. En

ambos casos se han pasado parámetros válidos e inválidos.

La primera gran prueba que debió pasar el sistema fue validar una petición correctamente

firmada, pero falló. Así que hicimos un seguimiento paso de paso de la ejecución, viendo cómo

se iba concatenando y codificando la cadena a firmar. Esta debería seguir lo descrito en la

sección 3.2.3, pero la biblioteca presentaba un fallo de implementación: codificaba los espacios

incorrectamente. Así que el primer paso fue corregirlo. El fallo se encontraba en la línea 658 del

archivo OAuthRequest.php. El cambio que hicimos fue pasar de

return $this->urlencode(rawurldecode($s));

a

return $this->urlencode(urldecode($s));

Un cambio sencillo, pero realmente difícil de encontrar. Más tarde descubrimos que es un fallo

ya reportado y que aún hoy sigue sin estar solucionado.

4.4. Páginas webEn esta parte se han desarrollado las siguientes páginas:

1. Página de login.

2. Explorador de archivos.

3. Página para enviar prácticas.

4. Página de error.

5. Lista las páginas de usuario.

6. Página de configuración.

7. Página de licencia y acerca.

2La codificación de los formularios enviados mediante objetos FormData con XMLHttpRequest, en las peticiones

AJAX, debe ser la codificación UTF-8.


En todas ellas se han tenido en cuenta como valores fundamentales la seguridad y la acce-

sibilidad. Más adelante se verán los aspectos que se han tenido en cuenta para cada apartado.

Además, el diseño de cada página y la eficiencia en ciertas partes tampoco se ha dejado de lado.

Para todo el desarrollo se sigue el conocido patrón MVC (Modelo-Vista-Controlador). Es

decir, se ha separado el desarrollo web en tres áreas: el controlador, que procesa las peticiones

y llama a las vistas; las vistas, encargadas de mostrar los datos a los usuarios y por último el

modelo, formado por las clases usadas por los controladores. En nuestro caso la comunicación

con el modelo se hace principalmente a través de la clase «BelenusValidator».

Cabe decir también que para este proyecto no se ha empleado ningún framework ni paquete

de reglas CSS para el desarrollo. Esto se ha debido entre otros motivos a la curva de aprendizaje

de estos, a que se ha seguido el desarrollo ya visto en Belenus y a que desde el principio se

consideró viable el desarrollo sin estas herramientas. Esto nos ha permitido tener una visión más

profunda de las tecnologías web involucradas en el proceso y su funcionamiento.

4.4.1. Implementación general de las páginasPágina de login

Esta página no debería verse nunca de utilizar LTI, o como mucho una única vez: cuando no

se recibe un nombre de usuario y aún no se tiene registrado el identificador de ese usuario. Esta

página es un simple formulario (ver figura 4.1). Además de eso, la página lleva a cabo ciertas

comprobaciones antes de mostrarse para generar avisos (por ejemplo, ya se ha iniciado sesión)

y también es la encargada de comprobar el usuario y contraseña, registrar el ID del usuario y

redirigir a la web a la que se quería ir inicialmente. En esta misma web también se muestra un

aviso si el login es incorrecto, dando al usuario la opción de volver a intentarlo.

Figura 4.1: Aspecto del formulario de login.

La principal utilidad de esta página aparece cuando se quieren utilizar todos los servicios

desarrollados sin usar LTI, que también es posible. En este caso, todo acceso pasará por ella.

Explorador de archivos

Esta es, junto a la página de envio de prácticas, la página más compleja con diferencia

de este proyecto. La idea era desarrollar un explorador de archivos que permitiese subir, des-

cargar, renombrar y eliminar los archivos del usuario y también del profesor. Este puede ser

un sustituto, más limitado obviamente, aunque más cómodo quizás, de la gestión FTP que se

realiza actualmente en Belenus. Es cierto que existen módulos web que igual podrían haberse

integrado para lograrlo, pero debido a que en gran medida el desarrollo para envío de prácticas

ha podido ser reutilizado para esta parte, hemos decidido seguir esa técnica. Además esto nos


aporta uniformidad en el diseño de las páginas y nos permite un control mayor para adaptarlo a

nuestras necesidades.

El aspecto general de la página es el que se aprecia en la figura 4.2. La funcionalidad se

agrupa en tres zonas distinguidas: la barra de navegación, la zona donde se muestran los ficheros

y la zona inferior para añadir nuevos ficheros.

Figura 4.2: Aspecto del explorador de archivos de Belenus.

Desde la barra de navegación podremos ir atrás, ir a la carpeta inmediatamente superior

(no hará nada si ya estamos en la raíz de nuestra carpeta de usuario), crear una nueva

carpeta, subir uno o más archivos y descargar en un archivo comprimido de la vista actual

(incluyendo carpetas y subcarpetas). Como es de suponer, en ningún caso seremos capaces

de hacer algo más allá de nuestra carpeta de usuario.

Desde la zona de archivos tendremos una lista de los archivos allí contenidos con sus

correspondientes iconos. Los iconos han sido obtenidos de [4] y [12] con ligeros retoques

para añadir más formatos o actualizar los ya existentes. Se soportan iconos para XML,

HTML, CSS, archivos comprimidos, audio, imagen, vídeo, archivos de texto plano, docu-

mentos de Microsoft Office, Photoshop. . . Al hacer clic sobre las carpetas accederemos a

su contenido, mientras que los archivos iniciarán su descarga. Además, todo contenido

posee un menú desplegable desde donde podremos renombrarlo o eliminarlo. A la hora de

renombrar, como al subir archivos, se comprueba que los nombres sean válidos y únicos.

Por último tenemos la zona inferior donde se pueden arrastrar ficheros para subirlos al

servidor o, en su defecto, hacer clic para subir ficheros como si de un input de tipo filese tratase. Esta ha sido quizás la parte más complicada de desarrollar en el lado del cliente.

Su funcionamiento se hace mediante la API de ficheros de HTML5. Al recibir los ficheros

estos se añaden a una petición que se envía mediante AJAX al servidor. En caso de que la

respuesta sea positiva se recarga la página para que se vea el resultado y, en caso contrario,

se muestra una página de error. Podemos ver un esquema de su implementación en el

fragmento de código 6.

Si el navegador no lo soportese, esta drag&drop zone no se mostrará y, para subir archivos,

se deberá usar el botón de la barra de navegación. Tenemos un ejemplo del código que se

ejecuta para comprobar si está soportada esta característica en el fragmento 9.


Figura 4.3: Aspecto de la barra de navegación de la página para enviar prácticas.

Figura 4.4: Funcionamiento del selector de profesor.

Pese a que el resto de la página es muy parecida, internamente el procesamiento en el

servidor cambia. Para empezar, ahora se está accediendo a un directorio ajeno y, por otro lado,

cambia el cómo saber qué ficheros mostrar. Pues en esa misma carpeta se almacenan archivos

pertenecientes a otros usuarios. De nuevo aquí ha sido vital no solo conocer la estructura de

carpetas del servidor Belenus, sino también cómo implementa ya esto. El funcionamiento es muy

simple, antepone a cada nombre de fichero la CUASI seguida de un guión bajo para identificar

al usuario. Esto es ocultado al usuario, que sube ficheros, los borra, visualiza, renombra. . . sin

percatarse.

Página de error

Esta es una página muy simple y que, en principio, no debería ver un usuario que realice un

comportamiento «normal» de la aplicación. La página simplemente sigue el estilo de diseño del

resto de páginas desarrolladas y muestra un mensaje en la zona central describiendo el problema

encontrado. Todos los errores que muestra esta página por ejemplo quedan registrados en el log.

Lista de las páginas de usuario

Esta web es un simple escaparate de las páginas de usuario y sirve como reemplazo a una ya

existente en Belenus. El motivo por el que se ha desarrollado, pese a ya existir, es que se quería

crear una página que pudiese mostrar solo un determinado número de usuarios y no todos si así

se quisiese. Además, ya de paso, se le ha dado un aspecto más moderno y se le ha dotado de

unos filtros de búsqueda. El aspecto logrado se puede observar en la figura 4.5.

Figura 4.5: Lista de las páginas de usuario.


La forma de listar los nombres es muy sencilla. En la petición LTI puede pasarse como

parámetro una lista de CUASI que serán las páginas de usuario a mostrar en sus correspondientes

columnas. Cuando solo se envía una CUASI se muestra directamente su página de usuario

asociada, mientras que, en caso de que no se reciba ninguna, se mostrarán todas las páginas

de usuario. Cabe señalar que en un principio se buscó que se obtuviese de forma automática

esta lista a partir de los alumnos matriculados en una asignatura. Sin embargo, esto no ha sido

posible pues Belenus no conoce esa lista y LTI tampoco la envía, ni da formas de hacerlo. Por

otro lado, los servicios REST de Blackboard, que puede que suplan esta funcionalidad, acaban

de salir y aún no se recomienda su uso en producción, además de no estar disponibles en la

versión utilizada por la universidad.

En cuanto a los filtros podemos apreciar dos filtros. El primero de ellos es un buscador donde,

a medida que escribimos, va acotando los usuarios en función de si tienen o no esa cadena de

texto en su nombre. El segundo es una simple lista de botones donde podemos elegir si mostrar

o no solo los usuarios cuyo nombre comience por una determinada letra. Notar que esta zona de

filtros puede ocultarse y mostrarse simplemente haciendo clic en el nombre de la categoría. Este

despliegue/ocultación se realiza suavemente mediante una transición de CSS3, si está disponible

en el navegador claro.

Página de configuración

Esta ha sido la última de las páginas desarrolladas dotada de funcionalidad. También es la

única donde se ha hecho uso de bibliotecas de jQuery para ampliar su funcionalidad. En concreto

hace uso de jQuery y de su extensión Chosen para generar los input.

Figura 4.6: Aspecto de la página de configuración con las preguntas y el XML generado.

El objetivo de esta página es facilitar la configuración de nuevos enlaces LTI a los profesores.

Para hacerlo, la página va mostrando una serie de preguntas muy simples y, en función de las

respuestas, genera un XML. Se puede ver un ejemplo en la figura 4.6. Este XML, como se verá

en el apéndice B, será junto con las claves la única configuración necesaria para crear un nuevo

enlace LTI.


El funcionamiento de esta página es continuo, sin recargas, gracias al uso de JavaScript y

AJAX. Las preguntas y el XML resultante se van mostrando y generando dinámicamente.

Página de acerca y licencias

Por último se han incorporado dos página más, accesibles desde el pie de página donde se

especifican licencias, contenido de terceros utilizado, autores. . .

4.4.2. AccesibilidadDesde el comienzo del desarrollo se han tenido en cuenta tres pilares fundamentales para

intentar que la mayor cantidad de usuarios puedan disfrutar de este servicio:

Compatibilidad con navegadores. Como referencia se ha tomado sobretodo la web [3],

donde podemos comprobar qué características de HTML, CSS o JavaScript se pueden

emplear y dónde. Con esto se ha buscado dar compatibilidad a los navegadores más

utilizados, en concreto aquellos que cuentan con más de un 0,5 % de cuota de mercado3.

En principio se han seguido los estándares para asegurarnos la compatibilidad con los

actuales y futuros navegadores, pero también se ha necesitado echar mano de ciertos trucos

para soportar navegadores más antiguos. Por ejemplo:

1. Debido a que se han empleado algunas reglas de CSS avanzadas que hacían uso

por ejemplo de la función «calc» o cambiaban la opacidad de un elemento se han

declarado usando alternativas o de forma que, en caso de no ser reconocidas, el

aspecto de la página no se vea muy afectado. En el código 7 se muestra un ejemplo.

.button-item {width: 200px; /* Para los que no reconocen calc*/width: calc(100% - 64px);

}.select-navegacion {

filter: alpha(opacity=0); /* Para IE8 */opacity: 0;

}

Código 7: Reglas CSS con alternativas para navegadores incompatibles.

Este comportamiento en ocasiones incluso se trata de replicar mediante JavaScript,

como se puede ver en 8. Este código solo se carga en versiones antiguas de Internet

Explorer gracias a condicionales4 en comentarios.

var btns = document.getElementsByClassName("button-item");for(var i = 0; i < btns.length; i++) {

btns[i].style.width = (size - 64);}

Código 8: Replicando reglas CSS no soportadas con JavaScript.

3Con este dato nos referimos a Internet Explorer 8, Edge 13, Firefox 45, Chrome 29, Safari 9, Opera 36, iOS Safari 8.4,

Android Browser 4.3, Chrome for Android 50, Opera Mini 8 y versiones posteriores.4Expresiones de la forma <!�[if lt IE 9]> código HTML <![endif]�>.


2. Debido a que el soporte de JavaScript cambia de un navegador a otro, se ha intentado

en todo momento garantizar la compatibilidad. A continuación, en 9 y 10, se incluyen

dos fragmentos que detallan cómo se ha hecho.

var tests = {drag: ’draggable’ in document.createElement(’span’),xhr: ’XMLHttpRequest’ in window,load: ’onload’ in new XMLHttpRequest(),fileReader: ’FileReader’ in window,formData: ’FormData’ in window,progress: "upload" in new XMLHttpRequest()

};

//Comprueba si el navegador soporta la zona de arrastrefunction hasSupport() {

return (tests.drag && tests.xhr && tests.fileReader &&tests.formData && tests.load);↪→

}

Código 9: Comprobando si el navegador soporta la zona de arrastrar y soltar archivos.

function letraclic(event) {var evt = event || window.event;var target = evt.target || evt.srcElement;...

}

Código 10: Soporte multinavegador5de eventos.

Compatibilidad con dispositivos móviles. Cada vez es más frecuente que se acceda a

muchas páginas desde dispositivos móviles. Es por ello que, para que todas las páginas

que se han desarrollado sean totalmente funcionales, se han empleado media queries en el

CSS. Estas son un tipo de reglas condicionales que cargan una regla o no en función del

tamaño de la ventana. Su aspecto se puede ver en el fragmento de código 11.

@media screen and (min-width: 568px) and (max-width: 852px) {.descripcion {

display: none;}

}

Código 11: Ejemplo de media query CSS.

Gracias a esta regla por ejemplo se logra que en ventanas cuya anchura varíe entre 586

y 852 píxeles CSS las descripciones no se mostrarán. Este tipo de reglas se han usado

para modificar las barras de navegación, tamaño de ciertos elementos, mostrar textos más

breves. . . En la figura 4.7 se muestra un ejemplo del explorador de archivos adaptándose a

distintos tamaños.

5La biblioteca jQuery lo hace de serie facilitándonos el trabajo si la utilizamos.


(a) Pantallas pequeñas. (b) Pantallas medianas.

(c) Pantallas normales.

Figura 4.7: Aspecto del explorador de archivos en distintos tipos de pantallas.

Gracias a estas reglas CSS se da soporte a tamaños de pantalla que van desde 320 píxeles

de ancho a tamaños superiores a los 1900 píxeles CSS6. Además, para garantizar que

en dispositivos móviles la aplicación se muestra a tamaño real, se usa la metaetiqueta

viewport, que podemos apreciar en el código 12.

<meta name="viewport" content="width=device-width,maximum-scale=1.0, user-scalable=yes">

Código 12: Ejemplo de media query CSS.

Debido a que Blackboard no se adapta a dispositivos móviles aún, estas funcionalidades

por ahora solo se podrán disfrutar si se abre el enlace LTI en una nueva pestaña/ventana,

que es precisamente el comportamiento por defecto.

4.4.3. Diseño de las páginas webAntes de empezar a diseñar las distintas páginas web que componen la aplicación se han

consultado las guías de diseño de la Universidad de La Rioja accesibles en [10]. De ahí se ha

tomado el logotipo de la universidad, así como los colores corporativos. Otros elementos no se

han elegido debido a su antigüedad, pues parte de la guía lleva más de 10 años sin actualizarse.

Para la elección de colores adicionales se han empleado la herramienta online de Adobe (ver [1])

que, a partir del color rojo UR7, ha generado otras tonalidades de rojo que se han usado en las

páginas de la aplicación.

4.4.4. SeguridadUno de los pilares de la aplicación web debe ser la seguridad. Este ha sido un tema recurrente

durante el desarrollo.

Una de las partes principales de este aspecto es la fase de autenticación. ¿Existe alguna

forma de engañar a la aplicación? En principio, si las claves se mantienen en secreto no. Como

6Notar que los píxeles CSS no equivalen siempre a un píxel real. En las pantallas de alta resolución, un mismo píxel

CSS puede representarse en varios píxeles reales.7Cuyo código hexadecimal corresponde a #990000, es decir, .


ya hemos dicho en la sección 3.1.5, el protocolo OAuth garantiza que las peticiones LTI no se

hayan manipulado, mientras que HTTPS se encarga de la autenticación de los servidores, así

como de que no viajen en claro los datos personales. Decir que, en cualquier caso, la seguridad

se deposita en Blackboard, pues es este el que identifica a los usuarios y Belenus simplemente

confía en él, bueno más bien en sus secretos compartidos.

Además, durante el desarrollo de las páginas web se han tomado medidas adicionales. Para

empezar se emplean directorios relativos a la carpeta de usuario buscando evitar que se pueda

acceder a zonas ajenas. Por otro lado, todo parámetro recibido del usuario es comprobado para

evitar valores incorrectos. Asimismo, con el fin de evitar inyección de código mediante XSS, todoSi no escapamos el conte-

nido antes de escribirlo, po-

dríamos estar permitiendo

que se incruste un script

malicioso que robe las cre-

denciales o cookies de los

usuarios.

contenido escrito de forma dinámica en las páginas web se hace previo escapado de entidades

HTML. Para conseguir este último paso el método que se observa en el código de 13.

$mode = ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML401;$encodig = "UTF-8";...echo htmlspecialchars($file[’name’], $mode, $encodig);

Código 13: Escapando el HTML para evitar inyección de código.

Notar que pone ENT_HTML401 en lugar de ENT_HTML5, pues hay ciertas entidades en el modo

HTML 5 con las que Internet Explorer 8 presenta problemas.

4.4.5. PrivacidadOtro de los aspectos que hemos querido tener en cuenta en el desarrollo es proteger los

archivos personales, así como su estructura de carpetas. Para evitar que esta información sea

conocida se toman dos medidas de seguridad:

Las páginas que contienen información privada, como aquellas relativas al explorador de

archivos, no deben ser guardadas en caché. Para conseguirlo hemos seguido los consejos

de [9] para fijar las cabeceras HTTP correspondientes. Estas se ven en el código 14.

header("Cache-Control: no-cache, no-store, ". "must-revalidate"); // HTTP 1.1.

header("Pragma: no-cache"); // HTTP 1.0.header("Expires: 0"); // Proxies.

Código 14: Cabeceras HTTP para evitar que se guarde en caché.

Por otro lado, toda la información que se envía se hace mediante POST para evitar que

quede en el historial de navegación. Sin embargo, esto planteaba un problema adicional: la

recarga de páginas, así como los botones de navegación de atrás y adelante del navegador,

presentan comportamientos anómalos. Para evitarlo hemos tenido que hacer uso del patrón

PRG (Post-Redirect-Get), es decir, cada petición POST al servidor, de tener éxito, devuelve

una redirección a la URL de visualización.

Por último, era inevitable que en estas URL de visualización se pasase información como

la carpeta en cuestión que queremos ver. Esta información en principio es privada y no

deseamos que pueda quedarse registrada en el historial del navegador. Es por ello que nos

planteamos pasar la información sobre el directorio actual cifrada en la URL. Por ejemplo,


mediante AES utilizando como clave el nombre de usuario o el ID de la sesión8. Pero

finalmente descartamos la opción al parecernos innecesaria y excesiva.

4.4.6. Eficiencia

En este aspecto se ha buscado limitar el número de peticiones por red y el tamaño de estas.

Por ejemplo, todas las imágenes utilizadas han sido comprimidas y el código JavaScript y

CSS ha sido minimizado9. Además se ha evitado hacer uso de muchas imágenes, bibliotecas

JavaScript. . . Por ejemplo, para el menú desplegable se ha usado un «sprite». Esto consiste que

en una misma imagen van varias, cuatro en nuestro caso, y por CSS se distingue entre ellas.

Se puede ver la imagen real junto a ejemplos de cómo se utiliza en 4.8. Hay páginas como

http://spritegen.website-performance.org/ que nos facilitan esta tarea.

.menuDesplegable {background-image: url(’<URL>’);background-repeat: no-repeat;background-position: -8px 0px;

}

.menuDesplegable:hover {background-position: -88px 0px;

}

#menuDesplegable-click {background-position: -88px -80px;

}

#menuDesplegable-click:hover {background-position: -8px -80px;

}

Figura 4.8: Código y sprite usados10para reducir el número de peticiones HTTP.

Por otro lado se ha consultado la documentación de Mozilla sobre código CSS eficiente (ver

[6]) para, en la medida de lo posible, hacer más ligera la tarea de renderizado. Esto ha consistido

principalmente en evitar reglas combinadas, comodines, relaciones entre elementos. . .

Al final de la fase de implementación hemos descubierto11 la gran potencia que nos añade

AJAX. Gracias al uso de esta técnica podríamos mandar respuestas mucho más ligeras que

solo incluyan por ejemplo los nuevos elementos del explorador. No obstante, debido a que este

cambio supondría replantearse gran parte de la funcionalidad de las páginas, el coste en tiempo

8La primera nos permitiría guardar esa URL en marcadores al no cambiar de una sesión a otra, la segunda no.9Esto es que se han creado versiones paralelas con extensión .min.js y .min.css donde desaparecen los saltos de línea,

los nombres de variables y funciones son mas cortos, no hay comentarios. . .10En realidad no es el sprite original, sino uno equivalente con los colores invertidos para que se visualice correctamente

en esta memoria.11Debido a la planificación que estamos siguiendo en el Grado en Ingeniería Informática, esta técnica no la hemos

conocido hasta el final del último año.


haría que se escapase del alcance de este trabajo. Es debido a esto que solo la página web de

configuración y la subida de ficheros hacen un uso de esta técnica.

4.5. PruebasAl final de la fase de implementación se han llevado a cabo las pruebas de integración donde

se ha comprobado el funcionamiento de todo el sistema. Durante esta fase se han descubierto

algunos errores que ahora se enumeran:

En la página de inicio de sesión el usuario podía modificar su ID de usuario, asignando su

usuario a cualquier ID de usuario. Aunque esto no permitía el acceso no autorizado, sí

podía provocar comportamientos anómalos. Se solucionó almacenando este dato también

en el servidor y comprobándose durante el envío.

Pese a que se utilizan rutas relativas, el usuario podía salir más allá de su zona de usuario

manipulando los parámetros y usando «..» para subir tantos directorios como quisiese. Se

han añadido comprobaciones adicionales a todos los parámetros recibidos para evitarlo.

Los ID de sesión se guardaban en ocasiones por duplicado y no venían asociados a

una plataforma (consumer_key), de forma que en caso de que ese ID se repitiese entre

plataformas se podía iniciar sesión en cuentas ajenas.

Los nombre de usuario recibidos del servidor LDAP no venían correctamente codificados.

A la hora de renombrar archivos o carpetas no se comprobaba si el nombre ya existía y

salía un error en lugar de mostrarse un aviso.

Se producía un fallo al descargar carpetas vacías.

En Internet Explorer 8 algunos eventos JavaScript y reglas CSS no funcionaban y han

tenido que ser adaptadas.

A través de una vulnerabilidad XSRF (Cross Site Request Forgery) se podían renombrar yEste ataque consiste en ha-

cer una petición a una URL

vulnerable, por ejemplo bo-

rrar un fichero. Si el cliente

tiene la sesión abierta, en-

tonces la petición se atien-

de y el fichero se elimina.

Y esto puede hacerse desde

cualquier página y sin au-

torización del usuario. Para

evitarlo hay que utilizan un

token, que haga que no se

pueda conocer de antemano

cuál es la petición válida.

eliminar prácticas y ficheros de nuestro directorio de usuario sin nuestro consentimiento.

Para evitarlo hemos incluido un parámetro adicional pseudo-aleatorio en las peticiones

POST que intervienen en este problema. Podemos ver cómo se genera este valor en el

fragmento de código 15 y como se comprueba su validez en 16.

$_SESSION[’xsrf_token’] = md5(uniqid(mt_rand(), true));

Código 15: Generación del token que se utilizará en ese sesión para evitar ataques XSRF.

if($_POST[’xsrf_token’] != $_SESSION[’xsrf_token’]) {$this->belenus->logMessage($_SERVER[’REQUEST_URI’] . " -Ataque XSRF detectado.");↪→

http_response_code(400);include_once("php/error.php");exit();

}

Código 16: Comprobación del token XSRF antes de realizar acciones de modificación.

Capítulo 5

Seguimiento y control

Como parte fundamental del éxito de un proyecto está la fase de seguimiento y control,

donde se sigue el avance de este y se van tomando medidas correctoras para controlar posibles

desviaciones y gestionar cambios. En este apartado de la memoria se detalla brevemente cómo ha

sido la evolución del presente Trabajo Fin de Grado, así como los cambios que han ido teniendo

lugar.

5.1. Control del alcance

En este apartado las diferencias de lo ocurrido respecto a lo planificado han sido mínimas y

el proyecto ha llegado con éxito a la meta prefijada. Se han cumplido no solo las metas mínimas

impuestas por el cliente que veíamos en el apartado 2.1.1, sino también las metas deseadas y

opcionales. Solo conviene mencionar un par de cambios.

Por un lado, la parte de recoger prácticas por parte de un profesor no se ha desarrollado de

forma separada. En su lugar, la funcionalidad ha quedado recogida en gestionar el directorio

personal, al ser la carpeta de prácticas un directorio más de este. Esta decisión se tomó al estudiar

la estructura de Belenus y ver cómo se almacenaban las prácticas.

Por otro lado, una de las ideas que, sin formar estrictamente parte del alcance, se ha desechado

durante el desarrollo del proyecto ha sido la de aceptar parámetros para los enlaces más allá de

los propios de LTI, por ejemplo en archivos de configuración. Esta idea se ha descartado debido

a que no aportaba funcionalidad adicional e iba en contra de la filosofía LTI y cómo envía este

los parámetros. La idea fue desestimada cuando, durante el despliegue y la configuración de

Blackboard, se vio que los profesores podían configurar sus propios parámetros en los enlaces

LTI de forma manual o mediante archivos XML, sin necesidad de trucos externos a LTI. Se

puede ver cómo hacerlo en el segundo anexo, sección B.2.3. Fue esta misma decisión la que

llevo a desarrollar una página de configuración que genere estos archivos XML.

Finalmente, hemos tomado la decisión de permitir usar también todo el desarrollo hecho

sin necesidad de utilizar LTI. Este cambio se justifica pues la mejora era importante y apenas

necesitaba de modificaciones para funcionar.

43

44 Capítulo 5. Seguimiento y control

5.2. Control de la planificación temporalEsta ha sido el eje central del seguimiento, debido a que la planificación inicial no se ha

seguido con exactitud y ha sido necesario controlar que se desarrollaba todo correctamente y

dentro de plazo. A continuación se muestran unas tablas y unos diagramas de Gantt donde se

puede apreciar de un vistazo una comparativa entre lo planificado y lo que finalmente ha ocurrido.

En los casos en los que se puedan notar desviaciones notables, se incluye una justificación.

5.2.1. Duración de las tareas

Código Tarea Tiempo est. Tiempo real Desviación

1.1.1 Planificación 15 horas 15 horas 0 %1

1.1.2 Seguimiento y control 15 horas 13 horas − 13,3 %2

1.1.3 Alcance y requisitos 5 horas 5 horas 0 %1

1.1.4 Reuniones 10 horas 8,5 horas − 15 %2

1.2.1 PHP 10 horas 10 horas 0 %1

1.2.2 Protocolo LTI 20 horas 22 horas + 10 %

1.2.3 Protocolo OAuth 15 horas 14 horas − 6,7 %

1.2.4 Belenus 20 horas 42 horas + 110 %

1.2.5 Blackboard 10 horas 10 horas 0 %1

1.3.1 Análisis y diseño 30 horas 17 horas − 43,3 %

1.3.2.1 Autenticación 20 horas 21 horas + 5 %

1.3.2.2 Páginas web 50 horas 72 horas + 44 %

1.3.3 Pruebas 20 horas 12 horas − 40 %

1.3.4 Documentación 15 horas 5 horas − 66,7 %

1.4.1 Memoria 30 horas 44 horas + 46,7 %

1.4.2.1 Hacer presentación 10 horas 10 horas 0 %3

1.4.2.2 Ensayar 5 horas 5 horas 0 %3

1 TOTAL 300 horas 325,5 horas + 8,5 %


Aquellas tareas marcadas con el superíndice 1 son las que se desarrollaron antes de la

planificación definitiva que se incluye en el proyecto, luego no presentan ninguna desviación.

Las del superíndice 2 aparecen con desviaciones estimadas, pues hasta después de la entrega de

esta memoria no se dispondrá de los valores finales. Mientras que aquellas señaladas con un 3

son tareas que aún no han empezado y quedan fuera del seguimiento mostrado en esta memoria.

La mayor parte de estas variaciones se deben a la incertidumbre a la hora de planificar que,

pese a lo tardío de esta, seguía existiendo. Aun así el proyecto completo se ha desarrollado

excediendo el tiempo previsto menos de un 10 %. Las desviaciones más significativas se han

producido en:

Belenus: El estudio del código fuente de Belenus supuso un esfuerzo menor del estimado.

Sin embargo, el hecho de tener que replicar el servidor LDAP para la autenticación ha

5.2. Control de la planificación temporal 45

descuadrado los tiempos de esta tarea. Además durante esa fase, al intentar abrir puertos y

desbloquear el firewall de la máquina de desarrollo se perdió su acceso, al ser por SSH,

retrasando aún más la tarea.

Análisis y diseño: Esta fase ha supuesto menos tiempo del inicialmente esperado, pues

gran parte de la tarea quedó diluida en el estudio de LTI, OAuth y Belenus, donde se iba

tomando nota de qué se iba a hacer y cómo se debía hacer.

Autenticación: Pese a que la desviación es de tan solo una hora, hemos creído conveniente

añadirla. La tarea hubiese costado menos de lo esperado completarla de no se por el citado

bug en la biblioteca OAuth elegida, cuya corrección nos llevó cerca de seis horas.

Páginas web: Aquí se observa de nuevo una importante desviación. Consideramos que la

desviación se debe a tres motivos principalmente:

1. Con el desarrollo ya en marcha nos percatamos de la necesidad de utilizar el patrón

PRG. Esto nos llevó a tener que rehacer ciertas partes de la aplicación con el

consiguiente retraso.

2. La creación de la página de configuración que, aun no costando mucho tiempo,

supuso retrasos al no estar inicialmente planificada.

3. El soporte a navegadores antiguos como Internet Explorer 8, que ha resultado ser

menos compatible con los estándares de lo esperado.

Pruebas: Esta parte ha supuesto menos tiempo del estimado. No porque no se hayan

hecho suficientes pruebas para ver que todo funcionaba correctamente y no presentaba

problemas, sino porque gran parte de estas han contabilizado para la fase de desarrollo. El

motivo por el que muchas se han contabilizado en las tareas 1.3.2.1 y 1.3.2.2 es porque

eran pruebas concretas que era mejor hacer en el momento, con las ideas frescas. Luego, a

la hora de contabilizar tiempos, era difícil separar.

Documentación: Consideramos que esta parte es la que peor se estimó. La tarea ha sido

mucho más corta de lo esperado pues no había tantas partes que documentar y gran

parte del esfuerzo de documentación se ha reflejado en la memoria (tarea 1.4.1). Además,

algunos comentarios que se iban incluyendo para facilitar el seguimiento del código se

han ido haciendo durante la fase de desarrollo, como ya ha ocurrido con las pruebas.

Memoria: Por último tenemos el caso de la memoria. Al final, redactar el contenido

restante y ajustar y repasar el resultado ha sido más costoso de lo esperado.

En la figura 5.1 podemos observar cómo nos hemos ido desviado en el número de horas

invertidas a lo largo del proyecto. Se observa por ejemplo un gran aumento en Semana Santa

que, en principio, estaba planificada como descanso y al final se tuvo que utilizar.


-10

0

10

20

30

Semana 1 Semana 5 Semana 9 Semana 13 Semana 17 Semana 21

Figura 5.1: Evolución de la diferencia de horas entre lo real y lo planificado.

5.2.2. Plazos de las tareasEn esta sección, en las figuras 5.2 y 5.3, se incluyen un par de diagramas de Gantt donde se

observa cómo ha sido el avance de las tareas. En verde tenemos las tareas que se han ejecutado

según la planificación, en amarillo aquellas que pese a estar planificadas en ese momento no se

han hecho entonces y en rojo se destaca aquellas tareas que se han hecho fuera de planificación.

De estar leyendo esta memoria en escala de grises, el amarillo se presenta como el gris más claro,

apenas distinguible del blanco, el rojo es el más cercano al negro, quedando el verde como tono

intermedio.

Tareas/Semana 01 02 03 04 05 06 07 08 09 10 11 12

Planificación

Seguimiento

Alcance

Reuniones

PHP

Protocolo LTI

Protocolo OAuth

Belenus

Blackboard

Análisis y diseño

Autenticación

Páginas web

Pruebas

Documentación

Memoria

Figura 5.2: Diagrama de Gantt planificado vs. real (parte 1/2).

Como se puede observar la tonalidad verde domina el diagrama, con no demasiadas zonas

amarillas y rojas. Algunas de estas se encuentran en:

La formación en LTI, OAuth sufrió ligeros retrasos debido a la carga de trabajos esas

semanas.

5.2. Control de la planificación temporal 47

La tarea de Belenus ha sufrido un retraso de dos semanas debido a la necesidad de replicar

el servidor LDAP.

Las tarea de Análisis y diseño y Autenticación han sido adelantadas una semana respecto

de la planificación original, aprovechando el tiempo extra de Semana Santa.

Ha habido algunos cambios en el plan bisemanal de reuniones. Esto se ha hecho para

ajustarse a los momentos más adecuados en los que convenía hacer la reunión.

Finalmente se aprecian ligeros retrasos en Autenticación y Páginas web. Estas concluyeron

la semana 17, cuando se hicieron los últimos retoques pendientes. Esto ha obligado también

a hacer cambios en las tareas Pruebas y Documentación.

En general, como hemos dicho, la planificación se ha seguido con puntuales excepciones.

Esto ha sido en parte gracias a la utilización de las semanas 9 y 17 (Semana Santa y exámenes

respectivamente) para ajustarse al cronograma. Esto es visible en la figura 5.7 donde se puede

ver, por ejemplo, que se invirtieron bastantes horas en Semana Santa.

Notar que hasta la semana 5 no se observa ninguna desviación pues la planificación final

de este proyecto aún no estaba terminada y por tanto se iba teniendo en cuenta el avance de las

primeras semanas para realizar el cronograma.

Tareas/Semana 13 14 15 16 17 18 19 20 21 22 23 24

Planificación

Seguimiento

Alcance

Reuniones

PHP

Protocolo LTI

Protocolo OAuth

Belenus

Blackboard

Análisis y diseño

Autenticación

Páginas web

Pruebas

Documentación

Memoria

Presentación

Ensayar

Figura 5.3: Diagrama de Gantt planificado vs. real (parte 2/2).

5.2.3. HitosDurante este proyecto se habían definido los hitos del cuadro 5.2. Como se puede apreciar

en dicho cuadro sí que ha habido cierto retraso durante el desarrollo intermedio que se ha

compensado con cierto margen que había al final y durante las tres semanas no lectivas (Semana


Santa y el periodo de exámenes). Esto se aprecia mejor en la figura 5.4, donde los valores

positivos representan adelantos y los negativos retrasos, ambos en tanto por uno. No obstante,

este desvío no ha sido tan acusado como pueda parecer al ver dos retrasos en los hitos de dos y

tres semanas juntos. El motivo de estos aplazamientos, como ya se ha explicado en el apartado

5.2.2, se debe a que se dejaron las tareas casi terminadas a falta de los últimos retoques, pero

no terminadas del todo. De hecho las líneas de progreso entre lo planificado y lo real se han

mantenido muy cerca como se aprecia en la gráfica 5.5.

Hitos Fin estimado Fin real

Fin de la planificación Semana 6 Semana 6

Fin de la formación Semana 7 Semana 9

Fin del análisis y diseño Semana 10 Semana 9

Fin de implementación Semana 15 Semana 17

Fin de pruebas Semana 16 Semana 19

Depósito del proyecto Semana 21 Semana 21

Defensa del proyecto Semana 23/24 Semana 23/24


-0,1

-0,05

0

0,05


Figura 5.4: Comparación del progreso completado entre lo real y lo planificado.

0

0,25

0,5

0,75

1


Planificado Real

Figura 5.5: Evolución del porcentaje de trabajo completado a lo largo del tiempo.

5.3. Otras gráficas 49

5.3. Otras gráficasPara terminar incluimos varias gráficas que muestran de forma más detallada cómo ha sido la

evolución. En la figura 5.6 se puede observar cómo se ha distribuido en general la carga a lo largo

de las horas de la semana, tomando como referencia los commit en el código. Como podemos

apreciar se ha tendido a trabajar por la noche antes que madrugar al ser más productivos durante

esas horas.

Lunes

Martes

Miércoles

Jueves

Viernes

Sábado

Domingo

0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00

Figura 5.6: Frecuencia según el momento de la semana con la que se ha hecho commit.

Además, en la figura 5.7 se puede apreciar cuántas horas se han invertido cada semana,

comparándolas con las cerca de 20 horas que se habían previsto.

0

10

20

30

40


Planificado Real

Figura 5.7: Comparación de horas invertidas semanalmente.

Conclusiones

Es al terminar este trabajo y echar la vista atrás cuando nos hemos dado cuenta de todo lo

alcanzado. No solo hemos cumplido con las metas de este proyecto, sino que por el camino

hemos aprendido sobre nuevas tecnologías y sobre cómo gestionar un proyecto. Por ejemplo,

gracias a la envergadura del proyecto, el mayor al que nos hemos tenido que enfrentar durante la

carrera, hemos visto realmente la importancia de una planificación para detectar desviaciones y

poder tomar medidas para cumplir plazos.

En cuanto a tecnologías hemos aprendido un nuevo lenguaje como es PHP y hemos conocido

las bases de LTI y de los protocolos OAuth y LDAP, ambos relacionados con la autenticación.

Esto nos ha acercado a documentos técnicos y especificaciones que hemos tenido que entender

para poder utilizarlas. Es gratificante ver que, gracias a estándares como estos, un trabajo, en

este caso la integración de Belenus en Blackboard, puede ser utilizado en muchos otros sitios,

otros CMS como Moodle, sin necesidad de cambios.

Pero no todo han sido buenas noticias, en este Trabajo Fin de Grado también nos hemos

encontrado con problemas. Nos hemos enfrentado a errores en bibliotecas que hemos tenido

que solucionar y hemos sufrido la dificultad de crear páginas web desde cero que sean seguras y

estén soportadas por varios dispositivos y navegadores. En gran parte debido a las diferencias

que presentan versiones antiguas de Internet Explorer con respecto a los estándares web. Es esta

cercanía a los protocolos la que nos ha hecho darnos cuenta, aún más, de la tarea de abstracción

que desempeñan ciertos frameworks y bibliotecas de desarrollo web. Estos nos hacen pasar

por alto algunos aspectos de seguridad y compatibilidad, limitando nuestro conocimiento en

beneficio de la legibilidad y el ahorro de tiempo que suponen una vez se sabe trabajar con ellos.

Además hemos visto de primera mano la necesidad de documentar y crear código legible,

pues hemos necesitado leer mucho código ya desarrollado. Hemos tenido que entender el código

fuente de la biblioteca OAuth para corregir un fallo y extender su funcionalidad. Así como

todo el código de Belenus, del que hemos tenido que deducir tanto su funcionamiento, como

la estructura del servidor donde se aloja. Aunque para este último también nos hemos podido

apoyar en los conocimientos que teníamos como usuarios de esta plataforma.

Por último citar un par de ideas que podrían servir para ampliar este proyecto.

Sería interesante crear en Belenus un sistema de evaluación de prácticas que se conectase

con Blackboard para registrar los resultados, dado que LTI soporta el envío de calificacio-

nes y Belenus la entrega de prácticas.

También podría ser útil crear un sistema que permita compartir la lista de alumnos de una

asignatura entre Belenus y Blackboard. Así se podría evitar ver una lista de páginas de

usuario tan grande en Belenus, lo que podría ser útil para un profesor a la hora de calificar

las páginas web.

51

Apéndice A

Reuniones de seguimiento y control

A lo largo del proyecto han tenido lugar varias reuniones con los tutores para realizar las

tareas de asesoramiento y seguimiento y control. A continuación se detalla una breve descripción

de cada una de ellas.

En la primera reunión, ver cuadro A.1, se reciben los primeros apuntes sobre el trabajo, se

detalla un poco más el contenido y se reciben los primeros documentos de Belenus. También se

habla de la necesidad de reunirse con José Manuel Sota, el otro tutor del TFG, para acordar el

alcance y más detalles del proyecto.

Fecha 1 de febrero de 2016 a las 10:15

Asistentes Eloy Javier Mata y Jorge Roldán

Duración 45 min.

Lugar Edificio Luis Vives, despacho 228

Cuadro A.1: Primera reunión.

La segunda reunión, ver cuadro A.2, sirvió principalmente para recibir los requisitos. En

ella también se habló sobre el protocolo LTI y su funcionamiento básico. Asimismo se acordó

recibir la máquina virtual de desarrollo de Blackboard la semana siguiente, para ello se dejó una

memoria USB donde se copiaría la información.


Asistentes José Manuel Sota y Jorge Roldán

Duración 40 min.

Lugar Fundación Universidad de la Rioja

Cuadro A.2: Segunda reunión.

En la segunda visita a la Fundación Universidad de la Rioja, ver cuadro A.3, se recibe

finalmente la máquina virtual de Blackbaord y las últimas instrucciones sobre esta.

53

54 Apéndice A. Reuniones de seguimiento y control



Duración 10 min.


Cuadro A.3: Tercera reunión.

La siguiente reunión, ver cuadro A.4, sirvió principalmente para tratar las ideas pensadas

para el proyecto. Se describió el alcance así como las ideas básicas que marcarían el desarrollo.

También quedó patente la necesidad de recibir el código que componía en ese momento Belenus.



Duración 35 min.


Cuadro A.4: Cuarta reunión.

En la quinta reunión, ver cuadro A.5, se discutió la planificación que se había estimado

para el proyecto, así como la descomposición de tareas de este. También sirvió para recibir una

copia del código fuente de Belenus, que marcó el inicio de su estudio. Por último también sirvió

para acordar los últimos detalles sobre la metodología a seguir, así como la decisión de no usar

un SGBD.

Fecha 11 de marzo de 2016 a las 10:10


Duración 45 min.


Cuadro A.5: Quinta reunión.

La sexta reunión, ver cuadro A.6, trató sobre todo lo aprendido en la fase de documentación

y las implicaciones en el proyecto. Se habló sobre LTI, OAuth, Belenus. . . En ella también se

resolvieron algunas dudas sobre la estructura de la memoria.

Fecha 21 de marzo de 2016 a las 11:50


Duración 55 min.


Cuadro A.6: Sexta reunión.

En la séptima reunión, ver cuadro A.7, se continuó hablando sobre la estructura general del

proyecto. También sirvió para comentar cómo iba avanzado el proyecto, así como los problemas

encontrados con LDAP y la biblioteca de OAuth.

55

Fecha 14 de abril de 2016 a las 11:25


Duración 30 min.


Cuadro A.7: Séptima reunión.

La octava reunión, ver cuadro A.8, fue una simple reunión de rutina donde se mostró el

avance de las primeras fases de implementación. En ella también se habló sobre cosas pendientes

de esta, así como posibles mejoras.

Fecha 29 de abril de 2016 a las 10:15


Duración 25 min.


Cuadro A.8: Octava reunión.

La novena reunión, ver cuadro A.9, y última antes de exámenes sirvió para mostrar cuál había

sido el resultado de la fase de implementación, a la que solo le faltaban unos últimos retoques.

También sirvió para hacer la primera entrega terminada de la memoria, correspondiente a los

capítulos del 1 al 3 y anexos B y C. El resto de capítulos y anexos seguían sin estar completos.

Fecha 20 de mayo de 2016 a las 11:15


Duración 15 min.


Cuadro A.9: Novena reunión.

La décima reunión tuvo lugar durante la semana de exámenes, ver cuadro A.10, y sirvió para

poner al día del resultado a José Manuel Sota. En ella se mostró cuál había sido el resultado, así

como se explicaron las decisiones tomadas y los problemas encontrados.

Fecha 26 de mayo de 2016 a las 9:20


Duración 1 h. 10 min.


Cuadro A.10: Décima reunión.

Posterior a la finalización de los exámenes y con toda la implementación terminada se

informó a Eloy Javier Mata del progreso. Se puede ver la descripción del encuentro en el cuadro

A.11. Aquí también se acordó la entrega de toda la memoria completada, a falta de revisiones, el

lunes 13 de junio.

56 Apéndice A. Reuniones de seguimiento y control

Fecha 7 de junio de 2016 a las 13:40


Duración 10 min.

Lugar Complejo Científico Tecnológico, despacho 3220

Cuadro A.11: Undécima reunión.

Finalmente, la última reunión que se recoge en este anexo, ver A.12, tuvo lugar la semana

previa al deposito del Trabajo Fin de Grado. En ella se habló sobre las últimas correcciones

pendientes de la memoria, así como los próximos pasos: entrega y defensa.

Fecha 16 de junio de 2016 a las 11:50


Duración 10 min.

Lugar Complejo Científico Tecnológico, despacho 3220

Cuadro A.12: Undécima reunión.

Apéndice B

Configuración de Blackboard

En este anexo vamos a ver cómo configurar los enlaces LTI en Blackboard. Notar que las

capturas de pantalla, así como las explicaciones, pertenecen a la versión 9.1 de Blackboard

en inglés y puede diferir en mayor o menor medida de la versión que utiliza la universidad

actualmente.

Para configurar los enlaces LTI en otras plataformas educativas como Moodle no se ha

desarrollado ninguna guía, aunque se recomienda la lectura de esta para hacerse una idea de qué

se necesita, sobre todo a nivel de URL y parámetros.

B.1. Configuración para administradoresPara esta parte necesitaremos iniciar sesión en Blackboard como administradores. En caso

de que no se disponga de dichos permisos se deberá usar la guía de profesores o contactar con

un administrador.

B.1.1. Creando enlaces LTIUna vez hayamos iniciado sesión como administradores, para dar de alta un nuevo TP,

debemos dirigirnos al área de administrador. Esta está situada dentro de la pestaña de «SystemAdmin» que aparece en la parte superior derecha de la página de inicio. Se puede ver cuál es la

pestaña en cuestión en la figura B.1.

Figura B.1: Cabecera de la página de inicio de Blackboard.

Una vez dentro de esta sección debemos buscar el enlace a la herramienta «Building Blocks»,

situada dentro de una categoría de igual nombre en la parte central derecha de la página. Dentro

veremos algo similar a la captura B.2. Aquí deberemos hacer clic, como es de esperar, en «LTITool Providers», tercera opción.

57

58 Apéndice B. Configuración de Blackboard

Building BlocksBuilding Blocks

Installed Tools

Configure or Delete Building Blocks that are included in the system.

Proxy Tools

Manage and register Proxy Tools and define their Global Properties.

LTI Tool Providers

Manage and register LTI Tool Providers.

Featured Building Blocks

Manage and install Featured Building Blocks

Figura B.2: Bloques de contenido.

En la nueva página que nos aparecerá se nos presentarán varias opciones:

1. Registrar un nuevo TP. Para ello hacemos click en «Register Provider Domain» y seguimos

los pasos que se ven en el apartado «Registrar un nuevo TP».2. Modificar un TP ya existente. Se nos mostrará un formulario similar al explicado en el

apartado «Registrar un nuevo TP», pero en este caso con los datos ya introducidos para

que podamos cambiarlos total o parcialmente.3. Añadir colocaciones/vistas a un TP ya existente. Ver apartado «Crear un nuevo emplaza-

miento».

Registrar un nuevo TP

Veamos ahora cómo es el proceso de registro de un nuevo TP y los datos que debemos

introducir. Como se puede apreciar en la figura B.3 los primeros datos que tenemos que dar son

el dominio, su estado (aprobado o excluído para LTI) y los host secundarios, si los hubiese.

En nuestro caso el dominio es belenus.unirioja.es, el estado debe ser «aprobado» y la lista de

nombres de host secundarios podemos dejarla vacía. Una vez rellenados estos datos llegamos a la

primera gran decisión a tomar: elegir a qué nivel queremos que estén las claves de autenticación.

Aquí hay dos opciones:

Si elegimos configuración global entonces todos los enlaces al TP compartirán una única

clave, que, en principio, solo los administradores conocerán. Es el más simple, pero

también el más limitado. Si optamos por este método, los profesores solo podrán añadir

vistas ya creadas y, por tanto no podrán añadir o modificar con parámetros propios las

peticiones. Por ejemplo, podrán crear enlaces a entregas de prácticas, pero no podrán dejar

seleccionado el profesor y la asignatura.

Si optamos por esta opción deberemos dar en esta pantalla el par clave-secreto que se

utilizará en la autenticación. Así como los parámetros que serán los mismos para todas las

peticiones a Belenus. En caso de marcar esta opción recomendamos ir echando un vistazo

ya al siguiente apartado para ver qué parámetros acepta cada enlace.

B.1. Configuración para administradores 59

Figura B.3: Registrando un nuevo TP (parte 1/3).

Mientras que si elegimos una configuración propia para cada enlace, será el profesor o

administrador quien, al crear una vista de un enlace, deberá definir, no solo los parámetros

personalizados, sino también las credenciales. Es pues mucho más versátil. Como des-

ventaja tenemos que añade complejidad de configuración y aumenta el número de pares

clave-secreto a gestionar, salvo que sea compartida con el consiguiente riesgo1.

Echamos en falta un modo intermedio donde las credenciales sean globales y aun así los

profesores y administradores tengan la posibilidad de fijar unos parámetros distintos para cada

colocación/enlace. No obstante, Blackboard no nos lo permite aun siendo posible según la

especificación como ya comentamos. Por tanto, la opción que recomendamos es la de fijar las

credenciales para cada dominio. Además, sugerimos que los administradores de Blackboard

creen por defecto los tres tipos de enlaces LTI soportados, para que los profesores los puedan

usar sin mayor complicación si así lo desean.

El último paso antes de terminar el registro de nuestro TP es decidir tres cosas más:

Si los datos de usuario se mandarán solo por SSL, por cualquier conexión o nunca.

Qué campos incluir sobre el usuario. Nos permite seleccionar rol, nombre y/o correo

electrónico.

Por último, hay que elegir si debe mostrarse un aviso al usuario cuando use dicho enlace y,

en caso afirmativo, cuál.

En el primer caso debemos marcar que los datos de usuario se envíen para que se pueda llevar

a cabo la identificación. En concreto recomendamos la tercera opción: «Send user data only overSSL». Para las otras dos configuraciones nuestro proyecto funcionará independientemente de qué

marquemos, luego no será necesaria ninguna configuración adicional más allá de lo que se desee.

1Si un secreto individual, no compartido, queda expuesto con anularlo bastaría. Mientras que siendo compartido

todos los enlaces quedarían expuestos y deberían actulizarse al nuevo secreto.


Crear un nuevo emplazamiento

Un emplazamiento o vista es una instancia a un enlace LTI que puede contar con parámetros

o credenciales propios o compartidos. Pueden ser creados por un administrador de Blackboard,

como veremos en este apartado, para que todo profesor pueda utilizarlos, o por un profesor para

usarlos en un momento puntual.

Cuando un administrador desea crear o editar un emplazamiento debe desplegar el menú sobre

un TP ya registrado y elegir «Manage Placements», como se puede observar en la figura B.4.

Figura B.4: Añadiendo y editando las vistas de un TP.

Esta opción nos lleva a una lista con los emplazamientos actuales, pudiendo añadir nuevos o

modificar los ya existentes como ya hemos dicho.

Para crear un nuevo emplazamiento debemos aportar los siguientes datos:

Etiqueta. Es el nombre con el que se mostrará en el curso dicho enlace.

Descripción.

Handle. Es un identificador único para este enlace.

Tipo de enlace. Determina dónde y cómo aparecerá.

Icono. Aquí podemos subir una imagen de 50× 50 píxeles.

URL del TP.

Además, si hemos optados por credenciales a nivel de enlace debemos dar el par clave-secreto,

así como los parámetros adicionales.

Es al elegir el tipo de enlace donde se nos presenta la segunda decisión. Aquí tenemos dos

grande opciones, como se puede apreciar en la figura B.5:

1. Que sea una herramienta de estudiante (Student tool).

2. O que sea una herramienta de contenido. De marcar esta opción podremos además permitir

que la propia herramienta LTI nos devuelva calificaciones que se añadan automáticamente

a nuestro cuaderno de notas. Esto puede ser interesante, pero en Belenus no nos servirá

B.1. Configuración para administradores 61

de nada. Además, dentro de esta opción podremos marcar varias opciones en función del

menú de herramientas donde queramos que le aparezca al profesor el emplazamiento para

incrustarlo en su curso. Podemos elegir los menús Tools, Assessments y Build (dentro de

este último, submenús Create y Mashups).

Figura B.5: Eligiendo donde queremos que aparezca la vista.

Por último conviene dejar claro qué parámetros admite cada enlace LTI de nuestra aplicación

y para que sirven. Notar que todos ellos son opcionales. Por ejemplo, en caso de no enviarse el

parámetro user, la primera vez que el usuario acceda a un enlace LTI se le pedirá iniciar sesión

quedando luego registrado para posteriores accesos.

Explorador de archivos

Aquí los usuarios pueden gestionar los archivos de su directorio personal: subir, renombrar,

eliminar, descargar. . .

URL https://belenus.unirioja.es/LTI/Explorar.php

Parámetro Valor Uso

user @[email protected]@X@ Permite identificar al usuario.

Entrega de prácticas

Aquí los usuarios pueden seleccionar un profesor y una de sus asignaturas para enviar prácticas

y editar o descargar los envíos ya realizados.

URL https://belenus.unirioja.es/LTI/EnviarPractica.php



profesor joroldan CUASI del profesor por defecto.

asignatura TFG Asignatura del profesor por defecto.

Lista de usuarios

Esta es la página donde se listan las páginas de los usuarios de Belenus. Admite un parámtetro

cuasis que determina el comportamiento:

Si está vacío muestra todos los usuarios.

Si contiene una única CUASI muestra directamente la página de usuario asociada a dicha

CUASI.


Si contiene varias CUASI muestra las páginas de únicamente esos usuarios.

URL https://belenus.unirioja.es/LTI/Explorar.php



cuasis cuasi1, cuasi2 Lista CUASI separada por coma-espacio.

B.2. Configuración para profesores

B.2.1. Insertando enlaces LTI ya creados

Para insertar enlaces LTI ya configurados es tan sencillo como acceder al contenido de un

curso y utilizar la barra superior (ver figura B.6) para añadirlo. Puede aparecer en cualquiera de

las categorías en función del tipo con el que se haya configurado.

Figura B.6: Añadiendo un enlace LTI ya configurado.

En el caso de que se haya configurado como herramienta de estudiante podremos mostrarla y

ocultarla en el apartado «Herramientas» de cada curso.

B.2.2. Activando la opción de crear enlaces LTI

Una opción más interesante, como ya venimos comentando, es crear nuestros propios enlaces

LTI. Pero antes deberemos marcar una opción que nos permita hacerlo.

La opción se encuentra en el panel lateral izquierdo del curso, dentro de «Customization»,

«Tool Availability». Si tenemos problemas encontrándolo nos podemos apoyar en la figura B.7.

B.2. Configuración para profesores 63

Figura B.7: Activando enlaces LTI para profesores.

Dentro, deberemos marcar la opción LTI, casilla de la primera columna (ver figura B.8), y

guardar los cambios.

Figura B.8: Opción a activar.

B.2.3. Creando nuevos enlaces LTIUna vez ya podemos crear nuestros propios enlaces LTI vamos a ver cómo hacerlo. El

primer paso en contar con un par clave-secreto que nos permita definir enlaces a Belenus. Si no

disponemos de uno deberemos pedirselo a los administradores de Belenus antes de continuar. Si

ya contamos con uno podemos continuar, no si antes recordar que debemos proteger el secreto

para evitar que las identidades de los usuarios se vean comprometidas.

A la hora de crear enlaces LTI podemos seguir la técnica ya vista para administradores

en el apartado «Crear un nuevo emplazamiento». Sin embargo tenemos también la opción de

utilizar un archivo XML. Con el objetivo de facilitar la generación de este archivo XML se

ha creado una página para ello. Así pues, se recomienda que los profesores que quieran crear


enlaces LTI con sus propios parámetros que accedan a https://belenus.unirioja.es/LTI/ConfigurarLTI.php. En dicha página se nos hacen sencillas preguntas sobre qué enlace

buscamos y se nos genera un XML en función de las opciones que marquemos.

Una vez tengamos los parámetros y el par clave-secreto de nuestro enlace LTI podemos

crearlo. Para hacerlo debemos ir al contenido de nuestro curso y en la barra superior (que ya

veíamos en la figura B.6), dentro de «Build content», elegir «Web link».

Una vez dentro, lo primero que debemos hacer es marcar la casilla «This link is to a ToolProvider» que vemos en la figura B.9.

Figura B.9: Casilla que debe quedar activada.

Una vez seleccionada y pegado el XML en el campo correspondiente la URL se rellenará

automáticamente y solo nos quedará ponerle un nombre, dar el par clave-secreto y elegir el resto

de opciones clásicas: descripción, fechas en las que será visible, seguimiento, se mostrará o no

en una nueva ventana (recomendamos que así sea para que se adapte a dispositivos móviles). . .

En caso de que no contemos con un XML y deseemos seguir el estilo clásico a la hora de dar

parámetros, con escribir la URL antes de marcar la casilla, el cuadro de texto para escribir el

XML se cambiará por otro campos para añadir los parámetros manualmente, como ya hacen los

administradores de Blackboard.

Apéndice C

Configuración del servidor Apache

Como ya hemos ido viendo a lo largo de la memoria Belenus utiliza un servidor Apache.

En la implementación de este proyecto hemos hecho uso de dos carpetas que no deberían ser

accesibles a través del navegador. Impedir el acceso a estos directorios en el servidor web es

sencillo. Tan solo debemos añadir un par de directivas (ver fragmentos de código 17 y 18) al

fichero de configuración y reiniciar el servidor para que los cambios surtan efecto.

<Directory "/var/www/php/LTI/config">Order Deny,AllowDeny from allOptions NoneAllowOverride None

</Directory>

Código 17: Bloqueando el acceso a los archivos de configuración.

<Directory "/var/www/php/LTI/php">Order Deny,AllowDeny from allOptions NoneAllowOverride None

</Directory>

Código 18: Bloqueando el acceso a las vistas.

En principio con esta configuración, a parte de las ya existentes, ya estaría cubierta la

configuración relativa a este proyecto. No obstante, durante el mismo desarrollo sí que han ido

apareciendo configuraciones adicionales que podrían resultar de interés. Igual ya no aplicarlas

de inmediato, pero sí al menos planteárselas. Estamos hablando de configuraciones como:

1. Limitar el tamaño de los archivos subidos.

2. Limitar los tipos de archivos admitidos en las carpetas de usuario por seguridad.

65

66 Apéndice C. Configuración del servidor Apache

3. Gestionar la caché. Por ejemplo para evitar que páginas privadas, como las propias de este

desarrollo, sean almacenadas. Así mismo, también para que páginas públicas puedan ser

cacheadas y de esta forma se acelere su acceso.

4. Comprimir las respuestas del servidor para ahorrar ancho de banda.

5. Cambiar la codificación por defecto de ISO-8859-1 a UTF-8.

Destacar que, ante la ausencia de esta configuración, las características 1, 3 y 5 se han

realizado de forma manual durante el desarrollo apoyándose en PHP.

Finalmente, para que este desarrollo funcione, se deberá copiar todo el código que compone

este proyecto y que se adjunta junto a esta memoria en la carpeta /var/www/php/. En concreto

deberá quedar todo el contenido dentro de esta carpeta, en el directorio LTI.

Bibliografía

[1] Adobe. https://color.adobe.com/.

[2] Blackboard Help, 2015. https://en-us.help.blackboard.com/Learn/9.1_2014_04/Administrator/080_Developer_Resources/020_Develop/General_Documentation/Template_Variables.

[3] Caniuse, 2015. http://caniuse.com/.

[4] Filetypeicons.com – FileSquare. http://filetypeicons.com/.

[5] Hammer-Lahav, Eran: The OAuth 1.0 Protocol. RFC 5849, Internet Engineering Task

Force (IETF), abril 2010. https://tools.ietf.org/rfc/rfc5849.txt.

[6] Hyatt, David – Mozilla Developer Network: Writing efficient CSS, 2000. http://www.mozilla.org/xpfe/goodcss.html.

[7] IMS Global Learning Consortium, Inc.: IMS Global Learning Tools Interoperability Im-plementation Guide v1.2 Final. enero 2015. https://www.imsglobal.org/specs/ltiv1p2/implementation-guide.

[8] Mata, Eloy J., Rubio, Julio y Pascual, Vico: Principales funcionalidades del servidor webBelenus. Comunicación y Pedagogía, (196), 2004.

[9] StackOverflow: Making sure a web page is not cached, across allbrowsers, 2015. http://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers.

[10] Universidad de La Rioja, 2005. http://www.unirioja.es/servicios/sc/index_diseno.shtml.

[11] Vickers, Stephen P. y Booth, Simon: Learning Tools Interoperability (LTI): A Best PracticeGuide. agosto 2014.

[12] Wikimedia Commons, 2015. https://commons.wikimedia.org/wiki/File:Oxygen15.04.1-folder-yellow.svg.

[13] Wikipedia: Tenencia Múltiple — Wikipedia, La enciclopedia libre, 2015.

https://es.wikipedia.org/w/index.php?title=Tenencia_M%C3%BAltiple&oldid=82631809, último acceso el 13 de abril de 2016.

[14] Wikipedia: Sistema de gestión de aprendizaje — Wikipedia, La enciclopedia libre,

2016. https://es.wikipedia.org/w/index.php?title=Sistema_de_gesti%C3%B3n_de_aprendizaje&oldid=88616933, último acceso el 10 de marzo de 2016.

67

TRABAJO FIN DE GRADO Interoperabilidad entre plataformas ... · Para empezar, la idea de integrar...

Documents

Transcript of TRABAJO FIN DE GRADO Interoperabilidad entre plataformas ... · Para empezar, la idea de integrar...