Phpbb Sessions Auth Bundle Laravel Package

Getting Started

1. Treat the package as a fork-first dependency. It is archived, GPL-3.0, and has no dependents. Check its composer.json before installing: it is likely Symfony 2.x/3.x-era and may not install on Symfony 5/6 without changes. Prefer a maintained fork or vendor it directly:

   composer require phpbb/phpbb-sessions-auth-bundle
   # if that fails:
   composer config repositories.phpbb-sessions vcs https://github.com/phpbb/PhpbbSessionsAuthBundle
   composer require phpbb/phpbb-sessions-auth-bundle:dev-master
   

2. Register the bundle using the mechanism for your Symfony version: AppKernel::registerBundles() for older apps or config/bundles.php for newer ones.

3. Configure the phpBB connection and cookie/session settings first. The bundle needs to read phpBB’s session and user tables, so point it at the same database phpBB uses and match phpBB’s cookie prefix/domain/path. The exact config keys are in the bundle’s DependencyInjection/Configuration.php; use that as the source of truth. The shape is typically:

   phpbb_sessions_auth:
       db:
           host: "%env(PHPBB_DB_HOST)%"
           name: "%env(PHPBB_DB_NAME)%"
           user: "%env(PHPBB_DB_USER)%"
           password: "%env(PHPBB_DB_PASSWORD)%"
           prefix: phpbb_
       cookie:
           prefix: phpbb3_
           domain: ".example.com"
           path: "/"
   

4. Wire it into the Symfony firewall. The bundle’s value is a phpBB-backed user provider/listener that hydrates the Symfony security token from a phpBB session. Start with one protected firewall:

   security:
       providers:
           phpbb:
               id: phpbb_sessions_auth.user_provider
       firewalls:
           main:
               pattern: ^/
               provider: phpbb
               # enable the bundle listener/firewall factory here
               anonymous: ~
   

   Verify the actual service IDs with:

   php bin/console debug:container phpbb
   

5. First use case: an existing phpBB board and a Symfony app on the same domain/subdomain where logged-in phpBB users should access Symfony routes without a second login. Put a simple protected route behind the firewall, log in through phpBB, then confirm Symfony sees the phpBB user and roles.

Implementation Patterns

• Shared-cookie SSO across subdomains. Run phpBB on forum.example.com and Symfony on app.example.com, set the phpBB cookie domain to .example.com, and keep Symfony’s session cookie name distinct. The bundle validates the phpBB session and turns it into a Symfony security token.

• phpBB as the source of truth for users. Do not create or edit Symfony users. Load identity from phpbb_users, groups from phpbb_user_group and phpbb_groups, and refresh on each request or with a very short cache. Treat Symfony’s user object as a request-scoped projection.

• Login redirect pattern. Let Symfony’s /login redirect to phpBB’s login page, then return to a Symfony callback route. Do not build a second password form unless you deliberately sync credentials back to phpBB.

• Logout must invalidate both sides. Symfony logout alone leaves the phpBB session alive; phpBB logout alone leaves the Symfony token until the next request. Use phpBB’s logout endpoint or invalidate the phpbb_sessions row, then clear the Symfony token and redirect.

• Role mapping from phpBB groups. Map phpBB group IDs to Symfony roles in a small service or by extending the bundle’s user provider. Keep the mapping explicit:

  // illustrative
  $roles = ['ROLE_USER'];
  if (in_array($groupId, [2, 5], true)) {
      $roles[] = 'ROLE_ADMIN';
  }
  

  Exclude phpBB’s anonymous user (user_id = 1), bots, and inactive users.

• Separate database connection for phpBB. Use a dedicated Doctrine connection or PDO service with read-only credentials. This keeps Symfony migrations and schema tooling away from phpBB tables and makes the boundary obvious.

• Use it as a reference implementation when modernizing. Because the package is archived, copy the listener/provider logic into your app rather than depending on it long-term. Keep the same concepts: read phpBB session cookie, validate session row, load user, build Symfony token.

• Protect only browser sessions. Do not use this bridge for stateless APIs, webhooks, or machine-to-machine auth. It depends on phpBB’s browser cookies and session table.

Gotchas and Tips

• Archived and unmaintained. Expect missing Symfony 4+/5+/6+ compatibility, old service definitions, and no security fixes. Pin a fork commit and budget time for upgrades.

• GPL-3.0 is a real constraint. If your Symfony app is proprietary, get legal review before linking or distributing a modified bundle. Forking the code does not remove the license obligations.

• phpBB session validation is more than “user_id exists.” phpBB sessions have expiry, session time, and lifecycle rules. If the bundle only reads phpbb_sessions.session_user_id, you may accept stale or forged sessions. Prefer validating through phpBB’s own session bootstrap where possible, or replicate its checks carefully.

• Cookie prefix confusion. phpBB’s cookie name prefix is configured in phpBB’s ACP, not necessarily the database table prefix. A mismatch means the bundle never sees the _sid/_u cookies. Check phpbb_config.cookie_name, cookie_domain, cookie_path, and cookie_secure.

• Symfony/phpBB cookie collision. Symfony often uses PHPSESSID; phpBB uses something like phpbb3_sid. Keep them distinct, but both must be on the same domain/path/secure settings for SSO. Test with Secure, HttpOnly, and SameSite settings.

• Anonymous sessions are common. phpBB creates sessions for guests. Always require session_user_id > 1 and a non-anonymous user before creating a Symfony token.

• Session garbage collection. phpBB’s phpbb_sessions table is pruned by phpBB. If you cache phpBB user data in Symfony, use short TTLs; otherwise deleted/logged-out users can linger.

• Debugging checklist:

  • Inspect cookies in the browser: _sid, _u, _k.
  • Query phpbb_sessions for the session_id from the cookie.
  • Confirm session_user_id and session_time.
  • Run debug:container and debug:event-dispatcher to verify listener registration.
  • Check Symfony’s security profiler panel for the token/provider used.
  • Look for firewall listener order problems: your phpBB listener must run before the context listener needs the token.

• Extension points are limited by age. The safest extension points are a decorated user provider, a custom role mapper, and a replacement session validator/listener. Avoid patching the bundle in vendor/; fork it into src/ or a private VCS repository.

• No ecosystem safety net. With zero dependents and 21 stars, there are few public examples. Read DependencyInjection/, Security/, and EventListener/ first; those directories tell you more than the README.