- What does the lbausch/flarum-laravel-session extension actually do?
- It is a Flarum extension that authenticates forum visitors using an existing Laravel session, so members already signed in to your Laravel application can open your Flarum forum without signing in a second time. Instead of building a custom SSO bridge, you let Flarum resolve the identity Laravel has already established. It is distributed via Composer and installed into the Flarum extensions directory.
- How do I install lbausch/flarum-laravel-session?
- Install it with Composer using composer require lbausch/flarum-laravel-session, then enable the extension in the Flarum admin panel. The Laravel app and the Flarum forum must share session state, which normally means aligning cookie name, cookie domain, session driver and encryption settings. Check the README for the exact configuration values before enabling it on a live forum.
- Which Laravel and PHP versions does version 0.6.0 support?
- Release 0.6.0 declares Laravel 13 as its only supported framework major and PHP 8.4 as its minimum language version. There is no supported intermediate configuration, so compatibility is binary rather than graded. Treat the floor as a hard requirement, not a soft recommendation.
- Can I install it on Laravel 12 or PHP 8.3?
- No, not at 0.6.0. Composer will hard-fail because the release constrains PHP to 8.4+ and illuminate/* to the 13.x line, so the only option on older platforms is to stay pinned to the latest 0.5.x release. Before relying on that, confirm the 0.5.x line is still receiving fixes. Migration to 0.6.0 should be tied to your Laravel 13 platform upgrade, not scheduled separately.
- How does Flarum authenticate users from a Laravel session?
- Flarum reads the session your Laravel application has already created and resolves the logged-in user from it, so the forum does not prompt for credentials again. The practical requirement is that both apps agree on session storage, cookie name, cookie domain and encryption or serialization details. If those do not line up, Flarum simply sees an anonymous visitor rather than throwing an error, which makes misconfiguration easy to miss.
- Do users need to exist in both Laravel and Flarum?
- The extension bridges authentication, but the identity it reads has to resolve to a Flarum user record for the member to appear with a profile, permissions and group memberships. Plan for provisioning or syncing users between the two systems, and decide what should happen when an identity exists in one but not the other. Check the README for how user lookup is resolved in the version you pin.
- Is upgrading from 0.5.x to 0.6.0 a breaking change?
- The break is environmental rather than API level: 0.6.0 drops Laravel 12 and older PHP support in a single minor release, so your integration code may be unchanged while the install constraint changes completely. Because the package is still on a 0.x line, assume any minor bump can be breaking-capable and pin to an exact version in composer.json. Avoid floating constraints for this dependency in production.
- Is there a maintained branch for Laravel 11 or 12 users?
- Nothing in the release notes confirms a maintained 0.5.x branch receiving security or bug fixes, so verify this with the maintainer before you depend on it. If no such branch exists, consumers on Laravel 12 and below are stranded at whatever 0.5.x last shipped. That is a material risk if the forum sits on a critical path in your application.
- Is this package safe to run in production?
- It is usable in production, but pin exact versions and treat it as a forward-looking dependency adopted in lockstep with your platform roadmap. Because 0.6.0 requires PHP 8.4 and Laravel 13 simultaneously, you are stacking a PHP minor, a framework major and a package minor upgrade into one change. Test on a staging copy of the forum first, since session misconfiguration tends to fail silently rather than loudly.
- What are the alternatives to sharing a Laravel session with Flarum?
- Alternatives include an OAuth or SSO bridge between the two applications, or syncing users through a Flarum API integration with its own token flow. Session sharing as implemented here is the simplest option when both apps run on the same domain and can share cookie configuration, but it couples the two deployments tightly. If they live on separate domains or separate session stores, a token-based bridge is usually cleaner.