Session Expiration Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony-Specific: The bundle is tightly coupled to Symfony 2.3+ (via symfony/security-bundle), making it only viable for Symfony-based applications. For Laravel/PHP projects, this is a non-starter unless abstracted via a wrapper or middleware layer.
• Session Management: The core functionality (idle session expiration) aligns with Laravel’s built-in session handling (session()->put(), session()->driver(), session()->migrate()), but Laravel’s session system is fundamentally different (e.g., no Symfony Firewall or EventDispatcher integration).
• Event-Driven Design: The bundle leverages Symfony’s event system (e.g., security.interactive_login, kernel.request). Laravel’s event system (Illuminate\Events) is compatible but requires custom event listeners to bridge functionality.
• Configuration-Driven: Uses Symfony’s YAML/XML config. Laravel’s config() system would need a custom facade or service provider to expose equivalent settings (e.g., session_expiration.timeout, session_expiration.idle_threshold).

Integration Feasibility

• Low Feasibility for Laravel: The bundle is not Laravel-native and lacks:
  • Laravel service provider integration.
  • Middleware support (Laravel’s primary session handling mechanism).
  • Eloquent/Query Builder compatibility (if storing session metadata in a DB).
• Workarounds Possible:
  • Middleware Approach: Reimplement logic in Laravel’s App\Http\Middleware\ExpireIdleSessions using request()->userAgent(), request()->ip(), and session()->lastActivity().
  • Event Listeners: Use Laravel’s Illuminate\Session\Events\Started to track idle time.
  • Package Wrapper: Create a thin Laravel package that adapts Symfony events to Laravel’s ecosystem (high effort, low ROI given Laravel’s simplicity).
• Database Dependency: If the bundle stores session data in a DB (unclear from docs), Laravel’s session()->driver('database') could conflict with Symfony’s assumptions.

Technical Risk

Key Questions

1. Why Symfony-Specific?

   • Is there a business requirement to use Symfony’s session system (e.g., legacy integration)?
   • If not, Laravel’s built-in session tools (session()->put(), session()->driver()) suffice with custom middleware.

2. Session Storage Mechanism

   • Does the bundle store session data in a DB? If so, conflicts may arise with Laravel’s database session driver.
   • Example: Symfony’s SessionHandlerInterface vs. Laravel’s DatabaseSessionHandler.

3. Idle Detection Logic

   • How does the bundle define "idle"? (e.g., last_activity timestamp vs. request frequency).
   • Laravel’s session()->lastActivity() can replicate this with minimal code:

     if (now()->diffInSeconds(session('last_activity')) > config('session.expiration')) {
         auth()->logout();
     }
     

4. Authentication Integration

   • Does it work with Laravel’s auth() system (Guard providers, Sanctum, etc.)?
   • Symfony’s SecurityBundle assumes a different auth flow (e.g., UserProviderInterface).

5. Performance Impact

   • Does the bundle add overhead (e.g., DB queries, event listeners)?
   • Middleware in Laravel is lighter than Symfony’s event-driven approach.

6. Fallback for Non-Symfony Projects

   • Are there alternative PHP packages (e.g., spatie/laravel-session-idle-timeout) that fit Laravel better?

Integration Approach

Stack Fit

• Laravel Incompatibility: The bundle is not designed for Laravel and lacks:
  • Laravel service providers (Illuminate\Support\ServiceProvider).
  • Middleware support (Illuminate\Http\Middleware).
  • Eloquent/Query Builder integration.
• Alternative Stack Options:

  Laravel Component	Symfony Equivalent	Integration Path
  Middleware	Event Listeners	Replace Symfony events with Laravel middleware.
  session()->driver()	SessionHandlerInterface	Use Laravel’s database/file drivers.
  auth()->user()	SecurityBundle	Use Laravel’s Guard system.
  Config files (config/)	YAML/XML	Publish config via config/services.php.

Migration Path

1. Assess Feasibility:

   • If the goal is idle session expiration, Laravel’s native tools (middleware + session()->lastActivity()) are simpler and more maintainable.
   • Example implementation:

     // app/Http/Middleware/ExpireIdleSession.php
     public function handle($request, Closure $next) {
         if (auth()->check() && now()->diffInSeconds(session('last_activity')) > config('session.idle_timeout')) {
             auth()->logout();
             return redirect()->route('login');
         }
         session(['last_activity' => now()]);
         return $next($request);
     }
     

2. If Symfony Integration is Required:

   • Option A: Hybrid Approach
     • Use the bundle only for Symfony microservices (if applicable).
     • Expose a REST API from Symfony to Laravel for session management.
   • Option B: Fork and Adapt
     • Fork the bundle and rewrite it as a Laravel package (high effort, low value).
     • Key changes needed:
       • Replace Symfony\Component\EventDispatcher with Illuminate\Events.
       • Replace SecurityBundle with Laravel’s auth() system.
       • Replace YAML config with Laravel’s config() system.

3. Dependency Mapping:

   Symfony Dependency	Laravel Equivalent	Notes
   symfony/security-bundle	laravel/ui, spatie/laravel-permission	Use Laravel’s auth system.
   ajgl/session-expiration	Custom middleware or spatie/laravel-session-idle-timeout	Prefer existing Laravel packages.
   EventDispatcher	Illuminate\Events\Dispatcher	Replace event listeners.

Compatibility

• Laravel Version Support:
  • The bundle requires Symfony 2.3+, which is ancient (Laravel 5.0+ uses Symfony 3.4+).
  • No compatibility with modern Laravel (8.x/9.x/10.x).
• PHP Version:
  • Bundle targets PHP 5.3+ (via Symfony 2.3).
  • Laravel 8.x+ requires PHP 7.4+.
• Session Drivers:
  • If the bundle assumes file-based sessions, Laravel’s file driver may work.
  • If it uses database sessions, conflicts may arise with Laravel’s database driver.

Sequencing

1. Phase 1: Proof of Concept (1-2 Days)
   • Implement idle session logic in Laravel middleware (no bundle).
   • Test with session()->driver('file') and database.
2. Phase 2: Feature Parity (3-5 Days)
   • Add config options (e.g., session.idle_timeout in config/session.php).
   • Integrate with Laravel’s auth() system (e.g., logout on timeout).
3. Phase 3: Performance Testing (1 Day)
   • Benchmark middleware vs. event-driven approach.
   • Validate no regression in session handling.
4. Phase 4: Rollback Plan
   • If the bundle is mandatory, document the forking effort and risks.
   • Otherwise, deprecate the bundle in favor of native Laravel solutions.

Operational Impact

Maintenance

• High Risk of Bitrot:
  • The bundle is unmaintained (no stars, stale PR).
  • Symfony 2.3 is EOL; dependencies may break in modern PHP.
• Laravel-Specific Overhead:
  • Custom middleware/listeners require ongoing testing for edge cases (e.g., AJAX requests, WebSocket activity).
• Dependency Management:
  • If forked, new Laravel releases may require updates to the wrapper layer.

Support

• No Community Support:
  • No GitHub issues