CONECTORES / LMS
Conectores con plataformas LMS
P2LRN utiliza el mismo Player y el mismo formato en LMS diferentes. La integración LTI 1.3 puede desplegarse en infraestructura propia y registrarse como herramienta externa; antes de una implantación conviene comprobar la versión, configuración y políticas de la instalación LMS de destino.
Descargas y requisitos para LMS
Las cinco plataformas documentadas son Moodle, Canvas, Sakai, Chamilo y Open edX. P2LRN no incluye un plugin distinto para cada una. El proveedor LTI se despliega una vez en un servidor propio y se registra como herramienta externa donde la instancia soporte LTI 1.3.
El ZIP contiene integration/lms: proveedor, servidor, SQLite, AGS, contratos y pruebas. Requiere Node.js 22.13+ y builds de Toolkit/Player; no es un instalador autónomo.Descargar fuente LTI (.zip)Guía LTI completa
Una plataforma propia puede cargar Player por NPM/CDN y usar Host Adapter sin LTI cuando ya dispone de identidad, autorización y persistencia.
Antes de registrar un LMS puedes validar un .p2lrn en el visor o con la CLI; el paquete no contiene credenciales ni datos de matrícula.
El proveedor debe desplegarse en una URL HTTPS administrada por la institución/proyecto y configurarse con sus claves y registros LMS reales.
Qué solución necesita tu plataforma
Para una web propia: <p2lrn-player> + Host Adapter. Tu plataforma autentica al usuario y decide estado, recursos, eventos y autoridad de notas.
Para un LMS compatible: despliega el proveedor P2LRN, registra OIDC/JWKS/launch/Deep Linking y autoriza AGS sólo cuando sea necesario.
SCORM, H5P, cmi5, QTI u otros formatos dentro de P2LRN son una capacidad del formato/Player; no equivalen a instalar una herramienta LTI.
No hay que convertir cada .p2lrn a SCORM ni crear un Player específico por fabricante.
Recorrido común del proveedor
- Administrador: despliega P2LRN LTI, registra la plataforma y sus deployment IDs, conserva claves/datos privados y publica cursos en el catálogo.
- Profesor: usa Deep Linking para elegir curso/unidad/actividad; si el LMS no lo soporta, un administrador puede preparar un binding manual autorizado.
- Alumno: abre la actividad; OIDC/JWT y el binding se validan antes de crear la sesión de Player.
- Progreso: estado y eventos se guardan por institución, despliegue, binding, alumno, intento, paquete, revisión y entidad.
- Notas: un resultado del navegador no es oficial por sí solo; el servidor valida la decisión y, con scopes AGS adecuados, la entrega al gradebook.
El proveedor y su E2E HTTP existen. La compatibilidad con una marca/versión concreta sólo debe anunciarse después de registrar y recorrer una instancia real de esa plataforma.
Moodle
La vía prevista es Herramienta externa LTI 1.3. El administrador habilita el uso de herramientas externas y registra el issuer y los parámetros suministrados por el proveedor. El profesor puede usar Deep Linking cuando la versión de Moodle y el despliegue lo soporten y estén autorizados.
Seguimiento: AGS permite enviar calificaciones sólo si hay permisos y un backend que valide el resultado. El resto de la actividad sigue reproduciéndose con el Player común.
Comprobaciones de la instancia
- Antes de cualquier registro, revisa que la instancia permite herramientas externas LTI 1.3 y qué servicios ofrece. No pegues URLs de ejemplo: utiliza únicamente las URLs HTTPS del proveedor P2LRN que hayas desplegado y verificado.
- Con el proveedor desplegado, registra sus URLs/clave pública, selecciona un recurso publicado y comprueba como alumno el acceso, la reanudación y, si corresponde, la calificación autorizada.
Canvas LMS
El administrador configura una herramienta LTI 1.3 mediante los mecanismos de registro y Developer Keys de la instancia. La selección de recursos puede usar Deep Linking y el libro de calificaciones AGS cuando estén habilitados por la institución.
El identificador de un recurso de Canvas no debe sustituir la identidad portable del paquete. Una copia de un curso puede cambiar los IDs propios del LMS sin alterar el contenido autorizado.
Comprobaciones de la instancia
- En el panel administrativo revisa la posibilidad de registrar una herramienta LTI 1.3 mediante Developer Key y las políticas institucionales de Deep Linking y AGS. Las claves, el cliente y las URLs deben proceder de un gateway P2LRN real.
- Valida con un curso de prueba: añade la herramienta, inserta una actividad publicada, ábrela con un usuario de alumno y comprueba persistencia y notas; copiar el curso no debe perder la identidad del contenido.
Sakai
El acceso previsto utiliza las herramientas externas LTI de Sakai. Antes de activarlo hay que identificar la versión y comprobar que el despliegue soporta LTI 1.3, el modo de lanzamiento y las capacidades de notas realmente instaladas.
El proveedor P2LRN valida el mismo contrato de identidad y contenido que para Moodle o Canvas, sin crear código especial de Player para Sakai.
Comprobaciones de la instancia
- Confirma que la versión de Sakai y su configuración de External Tools soportan LTI 1.3 y el mecanismo de registro del proveedor. Anota los servicios que están habilitados y autorizados.
- Con el proveedor desplegado, prueba el lanzamiento desde una lección, la sesión de alumno, la reanudación y el envío de calificación sólo cuando AGS esté disponible.
Chamilo
La disponibilidad concreta de LTI 1.3 y sus servicios varía según la versión de Chamilo y los componentes configurados. Primero hay que comprobar las capacidades efectivas de esa instancia; no se debe prometer Deep Linking ni AGS sin verificarlos.
Si no existe un consumidor LTI 1.3 compatible, la alternativa requiere una integración propia del host con Player y autenticación de la plataforma, no una simulación insegura de LTI.
Comprobaciones de compatibilidad
- Identifica primero la versión de Chamilo y los módulos LTI que tiene activados. Si sólo ofrece otros mecanismos de integración, no se debe presentar el conector LTI 1.3 como compatible.
- Cuando exista un consumidor LTI 1.3 apto, registra el proveedor y valida login, contenido publicado y calificación; de lo contrario utiliza una integración propia de Player/Host Adapter con autenticación autorizada.
Open edX
El recorrido previsto pasa por el componente LTI Consumer XBlock configurado para LTI 1.3. La apertura del recurso y la entrega de calificaciones dependen de la versión instalada y de los servicios autorizados.
Debe probarse la experiencia del alumno con las restricciones reales del sitio: sesión, incrustación, persistencia y finalización.
Comprobaciones de la instancia
- Verifica que el curso utiliza el LTI Consumer XBlock adecuado y que los servicios de la institución aceptan el lanzamiento de herramientas externas. El XBlock y sus permisos son responsabilidad del despliegue Open edX.
- Con el proveedor P2LRN desplegado, ensaya apertura como alumno, finalización, persistencia, navegación incrustada y envío de notas donde esté permitido.
Datos que corresponden al LMS y a P2LRN
Contenido, grafo de unidades y actividades, recursos, perfil de reproducción y packageId + contentRoot para identificar la revisión portable.
Usuarios, matrícula, políticas de centro, intentos privados, tokens, permisos, calificaciones oficiales, sesiones y almacenamiento durable.
loadState, saveState, reportScore, emitEvent y resolveResourceUrl. El navegador entrega datos; la autorización y la validación final siguen en servidor.
Registro por institución, verificación OIDC/JWT, catálogo y binding de contenido, sesiones, estado/eventos y envío autorizado AGS.
Datos de configuración del proveedor
El registro se hace con valores reales del despliegue, nunca con placeholders. El proveedor necesita tanto sus propias URLs como los identificadores y endpoints confiables del LMS.
issuer · client_id · deployment_idIdentidad y despliegues de la plataforma LMS que el administrador ha autorizado.
OIDC auth URL · token URL · JWKSEndpoints del LMS usados para login, validación y, cuando corresponda, OAuth2 AGS.
/lti/login · /lti/launch · /lti/deep-link · /lti/jwksRutas HTTPS del proveedor self-hosted que se registran en la herramienta externa.
AGSScopes de score y, sólo si se necesitan, lineitem.readonly/lineitem. NRPS no está implementado actualmente.
Consulta Módulo LTI 1.3 para instalación, límites y seguridad.
Pruebas necesarias antes de anunciar compatibilidad
- Registrar la instancia real y demostrar rechazo de issuer, client ID, deployment o firma incorrectos.
- Comprobar state/nonce, expiración y replay; copiar el curso no debe permitir abrir otro contenido por manipular IDs.
- Profesor selecciona un contenido publicado por Deep Linking o binding administrativo; alumno abre exactamente esa revisión.
- Estado y reanudación quedan aislados entre usuarios, intentos, cursos y revisiones.
- Si hay AGS, una nota validada llega a la columna correcta sin duplicados y sin crear lineitems sin scope.
- Probar cuestionarios, juegos 3D, SCORM/H5P, recursos protegidos, iframe/cookies y móvil en la versión concreta del LMS.
El proveedor ya tiene pruebas automatizadas comunes; esta matriz por LMS es la evidencia que todavía falta para convertir “compatible por estándar” en “validado en esta versión concreta”.