Contrib.social

ECA Plugin to handle sessions

Open on Drupal.org →
Created on 29 April 2025, 14 days ago

Problem/Motivation

Site builders using ECA lack any first-class integration with Drupal’s Session Layer. While contrib modules like Session Limit provide session-management logic (e.g. maximum concurrent sessions), ECA cannot hook into or manipulate session data because:

There is no “Session” plugin type in ECA’s events or actions registry.

ECA events cover user-entity operations (login, logout) but not low-level session events or session-entity contexts.

ECA actions cannot load, inspect, or terminate session records via Drupal’s Session Layer API.

This prevents reuse of ECA’s powerful modelling UI to implement session-related workflows (throttling, auditing, forced logout, notification of stale sessions, etc.), and forces site builders to install and maintain separate modules outside of ECA.

Steps to reproduce

Install and enable ECA (with ECA User).

Browse ECA’s Events: you see eca/user/events/user_login and user_logout but no session-specific events (e.g. session_create, session_destroy).

Browse ECA’s Actions: you see user-entity and content-entity operations, but nothing under a “Session” category.

Attempt to model “limit to 1 session per user” by reacting on user_login—no action exists to inspect or delete other sessions.

Observe that session data in the sessions table or via the session handler is unreachable to ECA.

Proposed resolution

Introduce a new plugin type eca_session:

Register a plugin discovery path src/Plugin/Eca/Session and category “Session.”

Define a base interface SessionEventInterface and SessionActionInterface to unify session-layer integration.

Add new ECA Session events, e.g.:

eca/session/events/session_create – fires when a new session is created.

eca/session/events/session_destroy – fires when any session is destroyed.

Add new ECA Session actions, e.g.:

Terminate sessions – configuration: user (entity:user), keep strategy (current, newest, oldest), optional max-count.

List sessions – expose session metadata for logging or notification workflows.

Invalidate session tokens – for use with Symfony-based session backends.

Leverage Drupal’s Session Layer API (Drupal\Core\Session\SessionManagerInterface and the session handler) rather than direct DB queries.

Update ECA’s plugin browser UI to show Session under both Events and Actions.

✨ Feature request
Status

Active

Version

2.1

Component

Code

Created by

🇨🇭Switzerland lukas.fischer

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @lukas.fischer
  • Comment 14 days ago →
    🇩🇪Germany jurgenhaas Gottmadingen

    This is a great idea. Here are a few comments:

    • This should go into the eca_user submodule, we don't need an eca_session submodule, I guess
    • Why should we require a new plugin type? Sounds like the functionality required can be done with the existing action plugins, and maybe conditions and events
    • When it comes to events, that's not that simple: events need to be dispatched by Drupal core at the point where you want someone else being allowed to subscribe to. So, when core wants to dispatch an event when a session is being created or destroyed, then core needs to provide that event and dispatch it. Once that's available, ECA will then be able to subscribe to those events. For now, I don't think, Drupal core allows that to happen, does it? There is an event AccountEvents::SET_USER which is dispatched when the current user is being set.
    • The action plugins listed above all make sense and should be fairly easy to implement.

    Sessions are something very delicate and it's probably easy to build something with security implications. So, we should be very careful with them, but the use cases are great and we should certainly go for it.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024