Actually this event is fired only when submitting credentials, no matter if the firewall is stateless or not.
Still not sure if it's a bug in the code or in the doc but, given InteractiveLoginEvent seems to be dispatched only when the authentication occurs because valid credentials are passed to the request, maybe AuthenticationSuccessEvent should indeed be triggered each time session is used?

Related to #20305.

@MacDada in your config here you don't have any authorization enforcing authentication, not even an anonymous enforcer (commented out). If you add that, does it work?

in your config here you don't have any authorization enforcing authentication

@iltar So what? Authentication !== Authorization. Why would I need any "authorization" check for "security.authentication.success" event to work?

BTW, I actually do have authorization configured – but on the controller level, not on the firewall level.

not even an anonymous enforcer (commented out)

If I required ROLE_USER, ROLE_ADMIN, etc on every path, then I'd need to uncomment that for login form to work. But I don't.

https://symfony.com/doc/2.8/security/form_login_setup.html#be-sure-the-login-page-isn-t-secure-redirect-loop

Anyway, I did a bit more debugging. It really is "strange". Notice that I use memcached to store sessions and do testing while being authenticated from remember me cookie. I check if the event is fired with a breakpoint here.

Scenario one: no authorization requirements in firewall and controller.

1. clear Symfony cache
2. restart nginx+php+memcached
3. fresh request: event gets fired
4. next request: event does not get fired
5. clear Symfony cache
6. request: event does not get fired
7. restart nginx+php+memcached
8. request: event does not get fired

So… I need to dump both Symfony cache and sessions storage for the event to fire. But dumping one of them is not enough…

Scenario two: IS_AUTHENTICATED_ANONYMOUSLY role required in firewall authorization.

#security.yml
security:
    access_control:
        - { path: ^/, roles: IS_AUTHENTICATED_ANONYMOUSLY }

Test and result same as above.

Scenario three: IS_AUTHENTICATED_ANONYMOUSLY role required in controller authorization.

<?php

namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Security;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Request;

class HomepageController extends Controller
{
	/**
	 * @Route("/", name="homepage")
	 * @Security("is_granted('IS_AUTHENTICATED_ANONYMOUSLY')")
	 *
	 * @param Request $request
	 * @return \Symfony\Component\HttpFoundation\Response
	 */
	public function homepageAction(Request $request)
	{

Test and result same as above.

Scenario four: IS_AUTHENTICATED_ANONYMOUSLY role required both in firewall and controller authorization.

Test and result same as above.

???

I also ran into this issue. Are there any news about this?

Is the documentation wrong, or should the symfony code be changed?

Ran into this issue today on 2.7.x

• InteractiveLoginEvent is dispatched only when submitting a form which is correct.
• AuthenticationEvent (success) will dispatch on each require ONLY if authenticated=false, but UsernamePasswordToken is serialized with authenticated=true

AuthenticationEvent is dispatched in

Documentation is saying

When a provider authenticates the user, a security.authentication.success event is dispatched. But beware - this event will fire, for example, on every request if you have session-based authentication.

Which is not quite true.

I've also hit this problem..

The documentation says that security.authentication.success fires on every request (when restoring from session), but that doesn't seem to be the case.

My workaround was to use a kernel.request event listener instead and do my work there. Not quite the same, but works well enough for my use case..

what's the status of this ?

Same problem on 4.3.3

This seems to be resloved by changing the documentation in symfony/symfony-docs#11457

So, if I want to modify user session status then should use the request listener instead ?

Authentication happens when an authentication listener proceeds an incoming request i.e. only when credentials are submitted.
When the security token is read from the session, it is already authenticated (and can be deauthenticated). So the bug is in the docs, not in the code.

If one comes with a common enough use case, we could consider dispatching a new event when the token is read from the session.