But doesn't the issue concern only the SecurityBundle map due to its per-request cache? Wouldn't mapping contexts by Request object hash instead of Request instances be enough, changing the\SplObjectStorage to an array?

@chalasr: The basic problem is the using of FirewallMapInterface to refer to long-lived services. There is no idea of destroying/detaching of FirewallMap from inside Firewall, because both of them are services and live forever.
Initially the FirewallMapInterface is intended only to get information and has nothing to initialize or to finalize itself. Even if we change the implementation of SecurityBundle\Security\FirewallMap to not have a Request reference, there will be a possibility to add a leak in the future.

@udavka : I don't get how it can improve anything when talking about the SecurityBundleFirewallMap. Unsetting the context for a given request won't free anything, as the services are still referenced by the container, right? The only leaking object is the request, indeed due to the\SplObjectStorage used for cache purpose. Usingspl_object_hash($request) instead is the only thing required for solving the issue to me.

Even if we change the implementation of SecurityBundle\Security\FirewallMap to not have a Request reference, there will be a possibility to add a leak in the future.

Which leak?

Regarding the componentFirewallMap, I don't get why you'd like to remove the listeners once a request is finished. What about subsequent requests? Are you destroying the listeners and recreating and adding them to the map for each request? If so, why? Aren't they stateless?
Also you don't need new interface methods/new interface nor tweaking theFirewall for this I guess: just register theFirewallMap as a listener ofKernelEvents::FINISH_REQUEST in order to calldetachListeners.

@ogizanagi Symfony is able to process many requests without restarting the whole framework. This idea is used in long-lived applications. Services are not leaks, because they are not recreated on every request. But Request is not a service and must be destroyed after the processing.
As you can see in the code, detaching of listeners is dependent on request, so no subsequent requests can be affected.
Using ofspl_object_hash($request) is not an option, because the resulting hash can be reused later and anyway there will be a small leak in form of an array item [hash => listener].
I seems that the idea aboutKernelEvents::FINISH_REQUEST is the only one possible solution to make this object not leakable without BC breaks, but in this case the whole logic of theFirewallMap object will be inverted - it is initialized by another component, but it wants to clean up itself. This is actually the big hole for future problems.

Using of spl_object_hash($request) is not an option, because the resulting hash can be reused later.

Indeed, as the previous request is destroyed as this point. Good point.

small leak in form of an array item [hash => listener]

Sure, but not sure how much it can really affect long-living applications, as its one array item (per request though) just holding references.

I seems that the idea about KernelEvents::FINISH_REQUEST is the only one possible solution to make this object not leakable without BC breaks, but in this case the whole logic of the FirewallMap object will be inverted - it is initialized by another component, but it wants to clean up itself. This is actually the big hole for future problems.

Looks acceptable to me, and would allow to be merged as a bugfix in lower branches.
Otherwise, creating a new interface would allow doing it your way without BC break, but only as a new feature, so in 3.4.

Since the matching context relates to the request, this information should have been cached inside the request parameters.

This inside thegetFirewallContext method.

// code in 3.2privatefunctiongetFirewallContext(Request$request)    {if ($this->contexts->contains($request)) {return$this->contexts[$request];        }foreach ($this->mapas$contextId =>$requestMatcher) {if (null ===$requestMatcher ||$requestMatcher->matches($request)) {return$this->contexts[$request] =$this->container->get($contextId);            }        }    }

We can remove the$contexts object map and store information inside the request attributes.

// proposalprivatefunctiongetFirewallContext(Request$request)    {if ($request->attributes->has('_security_firewall_context')) {return$this->container->get($request->attributes->get('_security_firewall_context'));        }foreach ($this->mapas$contextId =>$requestMatcher) {if (null ===$requestMatcher ||$requestMatcher->matches($request)) {$request->attributes->set('_security_firewall_context',$contextId);return$this->container->get($contextId);            }        }    }

Indeed,@GromNaN's suggestion looks even better to me :)

Status: needs work

Closing in favor of#22943