Haytni v0.0.1 Haytni.RememberablePlugin View Source

This plugin makes artificialy last user’s authentification by creating a cookie which stores a token for remembering the user.

This cookie is cleared when user’s manually logout.

Fields:

  • remember_token (string, nullable, unique, default: NULL): the token to sign in automatically (NULL if the account doesn’t use this function)
  • remember_created_at (datetime@utc, nullable, default: NULL): when the token was generated (also NULL if the account doesn’t use this function)

Configuration:

  • remember_for (default: {2, :week}): the period of validity of the token/which the user won’t be asked for credentials
  • remember_salt (default: ""): the salt to (de)cipher the token stored in the (signed) cookie
  • remember_token_length (default: 16): the length of the token (before being ciphered)
  • remember_cookie_name (default: "remember_token"): the name of the cookie holding the token for automatic sign in
  • remember_cookie_options (default: [http_only: true]): to set custom options of the cookie (options are: domain, max_age, path, http_only, secure and extra, see documentation of Plug.Conn.put_resp_cookie/4)

Routes: none

Link to this section Summary

Functions

Returns if this plugin is enabled

Check if the user is in a valid state. This callback is intended to let know others plugins if we should reject the login (and why)

This callback is invoked when a user is editing its registration and change its email address. It is a facility (subset) to avoid you to handle it by yourself via validate_update_registration/1

Invoked when an authentification failed (wrong password). It receives the concerned account and a Keyword to return after updating it if any change have to be done to this user

Invoked to accomplish a task right after user’s registration (insert). This callback allows you to do some linked changes to the database, send an email or whatever by appending it to multi

Returns the routes as a quoted fragment to be injected in application’s Router

This callback let you do any kind of change or additionnal validation on the changeset when a user is registering

Same as validate_create_registration but registration’s edition as logic between the two may be completely different

Link to this section Functions

Returns if this plugin is enabled.

Check if the user is in a valid state. This callback is intended to let know others plugins if we should reject the login (and why).

Returns false if the user is allowed to login else {:error, reason} where reason is a string, an informative to be directly served to the end user.

For example, you may want to have some kind of ban plugin. This is the way to decline the login:

def invalid?(%{banned: true}), do: {:error, :banned} # or: {:error, dgettext("myapp", "you're banned")}
def invalid?(%{banned: _}), do: false

Callback implementation for Haytni.Plugin.invalid?/1.

Link to this function on_email_change(multi, changeset) View Source

This callback is invoked when a user is editing its registration and change its email address. It is a facility (subset) to avoid you to handle it by yourself via validate_update_registration/1.

It returns a tuple of {Ecto.Multi, Ecto.Changeset}, same as its arguments, to permit to the callback to add any operation to multi or change to changeset.

This callback is called before updating the user but the actions added to multi will be run after its update.

Callback implementation for Haytni.Plugin.on_email_change/2.

Link to this function on_failed_authentification(user, keywords) View Source

Invoked when an authentification failed (wrong password). It receives the concerned account and a Keyword to return after updating it if any change have to be done to this user.

For example, you can use it as follows to count the number of failed attempts to login:

def on_failed_authentification(user = %_{}, keyword) do
  Keyword.put(keyword, :failed_attempts, user.failed_attempts + 1)
end

Note: we choose to use and pass keyword as an accumulator to let the possibility to plugins to deal themselves on a conflict (several different plugins which want to alter a same field). Even if Keyword allows a same key to be defined several times, you’ll probably don’t want it to happen as the last defined value for a given key will (silently) override the others.

Callback implementation for Haytni.Plugin.on_failed_authentification/2.

Invoked to accomplish a task right after user’s registration (insert). This callback allows you to do some linked changes to the database, send an email or whatever by appending it to multi.

Remember to comply to Ecto.Multi functions. In particular Ecto.Multi.run: the function called by it have to return {:ok, your value} or {:error, your value}. Also note that the inserted user will be passed to the function called by Ecto.Multi.run as the :user key to the map received by the last one as its (only) argument.

The following example illustrate how to send a welcome mail:

def on_registration(multi = %Ecto.Multi{}) do
  multi
  |> Ecto.Multi.run(:send_welcome_email, fn %{user: user} ->
    send_welcome_email_to(user)
    {:ok, :success}
  end)
end

Callback implementation for Haytni.Plugin.on_registration/1.

Link to this function remember_for(default \\ {2, :week}) View Source
Link to this function remember_salt(default \\ "") View Source
Link to this function remember_token_length(default \\ 16) View Source

Returns the routes as a quoted fragment to be injected in application’s Router

Callback implementation for Haytni.Plugin.routes/2.

Link to this function validate_create_registration(changeset) View Source

This callback let you do any kind of change or additionnal validation on the changeset when a user is registering.

Callback implementation for Haytni.Plugin.validate_create_registration/1.

Link to this function validate_update_registration(changeset) View Source

Same as validate_create_registration but registration’s edition as logic between the two may be completely different.

Callback implementation for Haytni.Plugin.validate_update_registration/1.