P2LRN

CONECTORES / LMS

Connectors with LMS platforms

P2LRN uses the same Player and the same format in different LMSs. The LTI 1.3 integration can be deployed on your own infrastructure and registered as an external tool; Before an implementation it is advisable to check the version, configuration and policies of the target LMS installation.

Downloads and requirements for LMS

The five documented platforms are Moodle, Canvas, Sakai, Chamilo, and Open edX. P2LRN does not include a different plugin for each one. The LTI provider is deployed once on your own server and registered as an external tool where the instance supports LTI 1.3.

LTI Provider Source

The ZIP contains integration/lms: provider, server, SQLite, AGS, contracts and tests. Requires Node.js 22.13+ and Toolkit/Player builds; It is not a standalone installer.Download LTI source (.zip)Complete LTI Guide

Player integrado directamente

Your own platform can load Player by NPM/CDN and use Host Adapter without LTI when you already have identity, authorization and persistence.

Portable trial course

Before registering an LMS you can validate a .p2lrn in the viewer or with the CLI; The package does not contain credentials or registration information.

There is no public shared gateway on p2lrn.org

The provider must be deployed to an HTTPS URL managed by the institution/project and configured with your actual LMS keys and records.

What solution does your platform need?

Player integrado directamente

For your own website: <p2lrn-player> + HostAdapter. Your platform authenticates the user and decides status, resources, events and note authority.

Herramienta externa LTI 1.3

For a supported LMS: deploy the P2LRN provider, register OIDC/JWKS/launch/Deep Linking, and authorize AGS only when necessary.

File Import

SCORM, H5P, cmi5, QTI or other formats within P2LRN are a capability of the format/Player; They are not equivalent to installing an LTI tool.

You don't have to convert every .p2lrn to SCORM or create a specific Player by manufacturer.

Common provider flow

  1. Administrator: deploys P2LRN LTI, registers the platform and its deployment IDs, preserves private keys/data and publishes courses in the catalog.
  2. Teacher: use Deep Linking to choose course/unit/activity; If the LMS does not support it, an administrator can prepare an authorized manual binding.
  3. learner: opens the activity; OIDC/JWT and binding are validated before creating the Player session.
  4. Progreso: Status and events are saved by institution, deployment, binding, learner, intent, package, revision, and entity.
  5. Notes: a browser result is not official on its own; the server validates the decision and, with appropriate AGS scopes, delivers it to the gradebook.
Implemented is not equivalent to certificate in all LMS

The provider and its E2E HTTP exist. Support for a particular brand/version should only be announced after registering and traversing a live instance of that platform.

Moodle

The planned route is Herramienta externa LTI 1.3. The administrator enables the use of external tools and registers the issuer and the parameters supplied by the provider. The teacher can use Deep Linking when the Moodle version and deployment support it and are authorized.

Follow-up: AGS allows you to send grades only if there are permissions and a backend that validates the result. The rest of the activity continues playing with the common Player.

Instance checks

  1. Before any registration, check that the instance allows external LTI 1.3 tools and what services it offers. Do not paste example URLs: only use HTTPS URLs from the P2LRN provider that you have deployed and verified.
  2. With the provider deployed, you register your URLs/public key, select a published resource, and check as a learner for access, resumption, and, if applicable, authorized grading.

Canvas LMS

The administrator configures an LTI 1.3 tool using the registration mechanisms and Developer Keys of the instance. Resource selection may use Deep Linking and the AGS Gradebook when enabled by the institution.

The identifier of a Canvas resource should not replace the portable identity of the package. A copy of a course can change the LMS's own IDs without altering the authorized content.

Instance checks

  1. In the administrative panel, review the possibility of registering an LTI 1.3 tool using the Developer Key and the institutional Deep Linking and AGS policies. The keys, client and URLs must come from a real P2LRN gateway.
  2. Validate with a trial course: add the tool, insert a published activity, open it with a learner user and check persistence and notes; copying the course must not lose the identity of the content.

Sakai

The intended access uses Sakai's external LTI tools. Before activating it, you must identify the version and verify that the deployment supports LTI 1.3, the release mode and the notes capabilities actually installed.

The P2LRN provider validates the same identity and content contract as for Moodle or Canvas, without creating special Player code for Sakai.

Instance checks

  1. Confirm that your Sakai version and your External Tools configuration support LTI 1.3 and the vendor registration mechanism. Note the services that are enabled and authorized.
  2. With the provider deployed, test launching from a lesson, learner session, resuming, and grade submission only when AGS is available.

Chamilo

The specific availability of LTI 1.3 and its services varies depending on the Chamilo version and the configured components. First you have to check the effective capabilities of that instance; Deep Linking and AGS should not be promised without verification.

If no supported LTI 1.3 consumer exists, the alternative requires a host's own integration with Player and platform authentication, not an insecure simulation of LTI.

Compatibility checks

  1. First identify the version of Chamilo and the LTI modules it has activated. If you only offer other integration mechanisms, the LTI 1.3 connector should not be presented as supported.
  2. When there is a suitable LTI 1.3 consumer, register the provider and validate login, published content and qualification; otherwise it uses a proprietary Player/Host Adapter integration with authorized authentication.

Open edX

The planned path passes through the component LTI Consumer XBlock configured for LTI 1.3. The opening of the resource and the delivery of ratings depend on the installed version and authorized services.

The learner's experience should be tested against the actual site constraints: session, embedding, persistence, and completion.

Instance checks

  1. Verify that the course uses the appropriate LTI Consumer XBlock and that the institution's services accept the release of external tools. The XBlock and its permissions are the responsibility of the Open edX deployment.
  2. With the P2LRN provider deployed, try opening as a learner, ending, persisting, embedded navigation, and sending notes where allowed.

Data owned by the LMS and P2LRN

In the P2LRN package

Content, graph of units and activities, resources, playback profile and packageId + contentRoot to identify the portable revision.

On the LMS or host server

Users, enrollment, school policies, private attempts, tokens, permissions, official grades, sessions, and durable storage.

In Host Adapter

loadState, saveState, reportScore, emitEvent and resolveResourceUrl. The browser delivers data; authorization and final validation continue on the server.

At the LTI provider

Registration by institution, OIDC/JWT verification, catalog and content binding, sessions, status/events and AGS authorized sending.

Provider configuration data

Registration is done with real values ​​from the display, never with placeholders. The provider needs both its own URLs and the LMS's trusted identifiers and endpoints.

issuer · client_id · deployment_id

Identity and deployments of the LMS platform that the administrator has authorized.

OIDC auth URL · token URL · JWKS

LMS endpoints used for login, validation and, where applicable, OAuth2 AGS.

/lti/login · /lti/launch · /lti/deep-link · /lti/jwks

HTTPS routes from the self-hosted provider that are registered in the external tool.

AGS

scopes of score and, only if they are needed, lineitem.readonly/lineitem. NRPS is not currently implemented.

Query LTI 1.3 Module for installation, limits and security.

Testing required before announcing compatibility

  • Register the actual instance and demonstrate rejection of incorrect issuer, client ID, deployment, or signature.
  • Check state/nonce, expiration and replay; Copying the course should not allow you to open other content by manipulating IDs.
  • Teacher selects content published by Deep Linking or administrative binding; learner opens exactly that review.
  • Status and resumption are isolated between users, attempts, courses, and reviews.
  • If there is AGS, a validated note reaches the correct column without duplicates and without creating lineitems without scope.
  • Test quizzes, 3D games, SCORM/H5P, protected resources, iframe/cookies and mobile in the specific version of the LMS.

The vendor already has common automated tests; This LMS matrix is ​​the evidence that is still missing to convert “compatible by standard” into “validated in this specific version”.