Document Security Events

[weaverryan]

See the SecurityEvents class for these 2:

• security.interactive_login
• security.switch_user

And AuthenticationEvents for these 2:

• security.authentication.success
• security.authentication.failure

We should at least have a mention of them somewhere and when you would use them. This relates partially to #802. I've also never been clear on security.interactive_login, it's name and PHPDoc suggests that there are other, non-interactive ways to login, and so that a listener to this would not cover all login cases. I'm not sure what that includes/doesn't include.

[wouterj]

It was introduced in fabpot/symfony#520 without any further comments. @schmittjoh can you maybe help us with this?

[stof]

@weaverryan when doing the authentication in the firewall, there is several ways it can be non-interactive:

• authenticating based on a remember me cookie
• authenticating based on the session (generally because you use an interactive login or a remember me cookie for a previous request)
• authenticating using a HTTP basic or HTTP digest header (which is sent alongside the request)

[stof]

and if you want to have a listener triggered for all authentication cases, it should listen to an authentication event: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/AuthenticationEvents.php

[weaverryan]

@stof Ah, I didn't even know about the AuthenticationEvents, awesome!

We have security.interactive_login that is trigged under most things that we thinking of as "logging in". And then we have the AuthenticationEvents, which are always triggered (even if it's really just that the user is browsing to a page and is being authenticated via a normal session cookie).

It seems to me that you'll want security.interactive_login if you want to do something after the user has physically logged in (e.g. set a lastLoggedInAt field on a User table). You would want to listen to security.authentication.success if... I'm not sure. Does anyone have a use-case here? Setting a lastActiveAt field? That doesn't seem like a very understandable use-case.

Thanks!

[stof]

For security.authentication.failure, good use cases are logging failed attempts (for instance to prevent retrying after too many failures.

For security.authentication.success, a use case could be user-based rate-limiting when implementing an API for instance (not sure it is the best place to implement though as this is just an idea I found at this time, without exploring to determine the better way to do it. There might be better ways). but the initial feature request was for the failure event. the success one was mainly added for consistency

[arnaugm]

What would be the best event to listen to in the case I want to show a message every time a user logs in (including remember me option enabled) and this user has some specific characteristics?

I understand that security.interactive_login is not enough.
If I use security.authentication.success, what happens when the user is authenticated but not authorized?

[arnaugm]

I just realized that security.authentication.success is triggered in every request, not only after the login. Now I understand better the reason of security.interactive_login.

I checked that the remember me cookie triggers security.interactive_login as well, which means that this feature is considered interactive.