Session Authenticator Event and Logging specifications

[kenjis]

The following is a list of the current implementation for Session Authenticator. Are these okay?

• default login
  • Post email/password
    • OK → event login / table auth_logins
    • NG → event failedLogin / table auth_logins
• email2fa login
  1. Post email/password
     • OK → no event / table auth_logins
     • NG → event failedLogin / table auth_logins
  2. Post token
     • OK → event login
     • NG → no event
• remember-me login
  • Send remember-me cookie w/o session cookie
    • OK → no event
    • NG → no event
• magic-link login
  1. Post email
     • OK → no event
     • NG → no event
  2. Send request with token
     • OK → event login / table auth_logins
     • NG → event failedLogin / table auth_logins
• default register
  • Post email/username/password
    • OK → event register and login
    • NG → no event
• register with email activation
  1. Post email/username/password
     • OK → event register
     • NG → no event
  2. Post token
     • OK → event login
     • NG → no event

[kenjis]

MGatner says:

• the term "login" should denote once authentication is complete, i.e. the user has no further Auth steps to take.
• anything that results in an authenticated user should trigger login.

If we agree with these, remember-me and magic-link are also logins, and should fire login event?

[lonnieezell]

Magic Link is definitely a login. Remember isn't, though, since it's an automatic thing and not something directly initialized by the user. I don't think that whatever someone might want to do after a login is the same thing they would want to do every time the load the page.

• email2fa login / Post email/password - I am probably confused about when exactly this is fired, but I thought we already added an event here? If this is after they complete the 2FA then yes a login event should be triggered.
• Magic links should have login and failedLogin events

Other than that I'm fine with the rest. If we want a failedRegister event to make things symmetrical, that's fine. I can't really think of a use for it, though.

[MGatner]

Wouldn't remember-me login only fire after the Session expired, and the long-term cookie was used to "refresh"? I don't have strong opinions on that either way, but it might be useful to have login records when that happens.

[lonnieezell]

Wouldn't remember-me login only fire after the Session expired, and the long-term cookie was used to "refresh"? I don't have strong opinions on that either way, but it might be useful to have login records when that happens.

Yes. I have never had a need to do an action when their session is renewed, though, and I can't really think of one. I think this would just be a performance hit and an unnecessary database filler if we were to log anything here. I also cannot think of a good reason to have an event fired at this point that couldn't be handled but custom filters. My thoughts is that it is such an edge case we leave it out until such a time as anyone asks for it. Which, with previous versions of Bonfire and Myth:Auth, no one has, yet.

[MGatner]

Sounds good. I agree this would be very niche, and probably more likely to have unwanted side effects.

[kenjis]

So, would the magic link be the following?

• magic-link login
  1. Post email
     • OK → no event
     • NG → no event
  2. Send request with token
     • OK → event login / table auth_logins
     • NG → event failedLogin / table auth_logins

[MGatner]

That looks good to me. Unlike 2FA there is no state for a magic link, so I don't think we need any events.

[lonnieezell]

Agree. This looks good to me.

[kenjis]

See https://github.com/codeigniter4/shield/blob/develop/docs/session_auth_event_and_logging.md