Pumukit Lms Bundle Laravel Package

Getting Started

First, calibrate expectations: this is not a Laravel package. teltek/pumukit-lms-bundle is a Symfony bundle built for PuMuKIT, Teltek's open-source video platform. With 2 stars, 0 dependents, and a 0.04 score, treat it as a reference implementation for LTI (Learning Tools Interoperability) integration, not a drop-in dependency. You will not composer require this into a Laravel app and get working code.

Where to look first, in this order:

1. composer.json — check the Symfony version constraint and PHP version. Most PuMuKIT LTI bundles target Symfony 3.4/4.x, not 6/7. This tells you whether you can read the code as a pattern or actually run it.
2. DependencyInjection/ — the bundle's Extension and Configuration classes. This is where the config tree lives; every tunable (LMS hosts, LTI consumer keys, route prefixes) is declared here. Read this before anything else.
3. Resources/config/services.yml (or services/) — the service wiring. Map services to their classes to understand the moving parts: LTI authenticators, user providers, controllers.
4. Resources/views/ — Twig templates. These reveal the actual LTI consumer-facing pages (launch handler, embedded player, error screens).
5. Controller/ — the HTTP entry points. Each *Controller corresponds to a route registered via Resources/config/routing.yml.

First use case: an instructor clicks a video link inside Moodle/Canvas → the LMS POSTs an LTI launch request → PuMuKIT validates it and renders a video player scoped to the course context. Everything in the bundle orbits that flow. If you're building a Laravel app that needs LTI-embedded video, your realistic day-1 task is: read the launch validation controller, then reimplement the signature/claims check in Laravel using oauth-php or a modern LTI 1.3 library — not install this bundle.

Implementation Patterns

Because this bundle only ships inside a PuMuKIT (Symfony) installation, "day-to-day" usage falls into three practical patterns for a Laravel developer:

Pattern 1 — Run PuMuKIT alongside Laravel and bridge over HTTP. Deploy PuMuKIT + this bundle as a dedicated video/LTI service. Your Laravel app talks to it via a small internal API (or shared session cookie). Laravel remains the source of truth for users; PuMuKIT owns LTI. This is the cleanest path and avoids reimplementing LTI.

Pattern 2 — Read the bundle as an LTI spec. The controller + validator pair is your working reference for:

• Parsing oauth_consumer_key, oauth_signature_method, oauth_timestamp, oauth_nonce, lti_version, lti_message_type, lis_person_*, lis_course_*, context_id, resource_link_id.
• HMAC-SHA1 signature construction (build the base string, sort params, URL-encode, sign).
• Mapping LTI claims into a local user/session.

Port the logic to Laravel (App\Services\LtiLauncher, App\Http\Controllers\LtiController), keeping the claim names identical so tests against Moodle/Canvas carry over.

Pattern 3 — Fork and add Laravel-as-consumer glue. If you maintain a PuMuKIT install, fork to add event subscribers (Symfony EventSubscriberInterface) for launch events — e.g., LtiLaunchEvent — and call out to your Laravel API for entitlement checks. Extension points to watch:

• Custom user provider — where LTI identity maps to a local user. Swap for a service that defers to Laravel's user API.
• Event dispatcher — subscribe to pre/post-launch to log or gate access.
• Config parameters — lms.hosts, lti.consumer_key, lti.consumer_secret, lti.return_url. These are set in app/config/parameters.yml (old PuMuKIT) or .env + config/services.yaml (newer).
• Routing prefix — set in Resources/config/routing.yml (something like /lti), so the LMS-visible URL is stable.

Integration tips:

• Register the bundle in AppKernel.php (new Teltek\PumukitLmsBundle\PumukitLmsBundle()) — this is conceptually config/app.php providers, but you must edit a file, not rely on discovery.
• Add the VCS repository ("repositories": [{"type": "vcs", "url": "https://github.com/teltek/PumukitLmsBundle"}]) since it's almost certainly not auto-registered on Packagist.
• Pin a commit hash in composer.json. With 2 stars and no releases, dev-master will silently break.
• Keep LTI secrets out of version control; PuMuKIT historically used parameters.yml, which is a common leak.

Gotchas and Tips

Framework mismatch is the biggest pitfall. There is no Laravel service provider, no facade, no config cache integration, no php artisan command. Every Symfony bundle convention (Extension, CompilerPass, Resources/config/) has to be mentally translated. Don't expect php artisan vendor:publish to work.

Symfony version lock. The bundle's composer.json likely constrains symfony/symfony or individual components to 3.x/4.x. If you're on Laravel 10/11 (Symfony 6/7 components underneath), you cannot install it side-by-side. Check composer why-not before assuming conflict.

LTI signature failures are the #1 debugging pain.

• Clock skew between LMS and server > 5 minutes → signature rejected. Install NTP.
• HTTPS is required by most LMSs; local http testing fails silently or with opaque errors.
• Parameter ordering matters in base-string construction. Symfony's request parameter bag may reorder; sort explicitly.
• Replay protection on oauth_nonce: a nonce cache is required. If the bundle relies on the session, it breaks across load-balanced nodes.

Cookies in iframes. LTI launches are always iframed. Modern browsers block third-party cookies by default. If your PuMuKIT session cookie is SameSite=Lax, launch will succeed but the authenticated session won't stick. Set SameSite=None; Secure on the LTI session.

Logging and debugging. Don't look for Telescope/Ray integration. Use Symfony's var/log/dev.log and dump() / dump-server. For LTI specifically, log the raw POST parameters before validation — the validator often swallows the exact failure reason.

PuMuKIT-specific gotchas.

• PuMuKIT versions 2 and 3 differ significantly; this bundle likely targets one. Match versions or you'll chase Class not found errors.
• pumukit:admin:create and related console commands are required for an admin user; without one you can't test the LTI linking UI.
• Asset pipeline: PuMuKIT uses Assetic/Encore depending on version. Twig templates in this bundle may reference assets that don't exist post-upgrade — inspect Resources/public/.

Production-readiness warning. 2 stars, 0.04 score, and 0 dependents is a strong signal that this is single-maintainer, low-traffic code. Do not put it directly in front of paying customers without a security review of the signature validation path. The most common bug class in old LTI bundles is inverted or missing oauth_signature verification — verify explicitly that a tampered lis_person_name is rejected before trusting the code.

Extension points to preserve if you fork:

• An event subscriber hooked to launch for audit logging.
• A user provider that maps lis_person_contact_email_primary to your Laravel identity store.
• A config-level whitelist of LMS consumer keys (lti.consumer_keys) so a single secret leak doesn't compromise every integration.

When in doubt, port, don't install. For a Laravel shop, the highest-leverage use of this repository is as a specification-by-example: ~200–500 lines of LTI launch/validate logic you can reimplement cleanly and keep under test with Laravel's HTTP test client, rather than maintaining a Symfony bundle you don't fully consume.