Sessions and CSRF

A page with three lists makes three more requests on the same session. Where the session storage locks the session from start to save (PHP's file handler does), they would run one after another.

With session.enabled (the default), a list request saves the session as soon as the firewall has loaded the user, before its controller runs. It also keeps the security firewall from reopening the session on the response, which would take the lock again and write a stale token over a concurrent sign-in.

A list still mints CSRF tokens while it renders: for its boolean toggles (ea-toggle) and its batch actions (ea-batch-action-<action>-<entity>). Stored in the session, they would reopen it. The bundle decorates security.csrf.token_manager so that those ids are checked by origin (Symfony's SameOriginCsrfTokenManager: the Origin, Referer and Sec-Fetch-Site headers) instead. Every other id, ea-delete included, stays with your token manager.

framework.csrf_protection.stateless_token_ids takes exact ids, and a batch id carries its action and entity, hence the prefixes.

easyadmin_embedded_list:
    session: false   # leave the session and the token manager alone