Add after_session_confirm hook after session confirmation

[wilburhimself]

fixes #213

This PR introduces a new after_session_confirm hook to the Passwordless gem. This feature allows users to perform custom actions after a session has been successfully confirmed, such as marking an email as verified or updating user attributes after their first successful login.

Changes

• Added after_session_confirm configuration option
• Updated SessionsController to call the hook after successful authentication
• Added new tests in SessionsControllerTest to cover the new functionality
• Updated README with documentation for the new feature

Motivation

Users of the gem often need to perform specific actions after a successful login, such as updating user attributes or triggering other processes. The after_session_confirm hook provides a clean, configurable way to achieve this without modifying the gem's core code.

Implementation Details

• The hook is called in the authenticate_and_sign_in method of SessionsController, right after successful authentication but before redirecting the user.
• The hook can be configured to accept either one argument (the session) or two arguments (the session and the request), providing flexibility for different use cases.
• If the hook is not defined or doesn't respond to call, it is silently ignored to maintain backwards compatibility.

How to Use

Users can configure the hook in their Passwordless configuration:

Passwordless.configure do |config|
  config.after_session_confirm = ->(session) {
    user = session.authenticatable
    user.update(email_verified: true)
  }
end

Testing

New tests have been added to SessionsControllerTest to ensure the hook is called correctly in various scenarios:

• Successful authentication
• Hook receiving both session and request objects
• Hook not being called on failed authentication

All existing tests pass with these new changes.

Reviewer Notes

• Please pay special attention to the placement of the hook call in SessionsController to ensure it's in the most appropriate location.
• Consider if any additional error handling is needed around the hook execution.
• Let me know if you think any additional tests or documentation would be beneficial.

Checklist

• [x] Code follows the style guidelines of the project
• [x] New tests added for the feature
• [x] All tests pass
• [x] Documentation (README) has been updated

[mikker]

Failing test is just rails#main

[mikker]

Great work! ❤️🧡💛💚💙💜

[wkirby]

@mikker when can we expect to see this released?

[mikker]

Just pushed 1.8.0 with this change 😊

[henrikbjorn]

Am I correct in assuming the controller context is lot in the hook ?

A use case would be for Ahoy to call ahoy.authenticate for analytics. But it seems that can't be done since the hook is "just" a function.

Would it make sense to instead define the hook methods on the controller (kind of like Devise)? Then the Controller context is kept, and it is also easy to set a custom controller to use.

[henrikbjorn]

Another note. It is not possible to have two different hooks. E.g one for AdminUsers and one for normal Users. Which having it as a controller method would handle.

[mikker]

Good points Henrik!

It could be useful to have the controller context at hand.

Maybe something like if setting the hook setting to a :symbol, a method with that name will be called instead?

Like

class ApplicationController < ...
  private

  def pwless_after_session_confirm(session) # no need to pass request either
    # ...
  end
end

Passwordless.configure do |config|
  config.after_session_confirm = :pwless_after_session_confirm
end

That would make it a non-breaking change.