View Source Lightning.Accounts.UserToken (Lightning v2.10.4)

The UserToken model.

The reason why we store session tokens in the database, even though Phoenix already provides a session cookie, is because Phoenix' default session cookies are not persisted, they are simply signed and potentially encrypted. This means they are valid indefinitely, unless you change the signing/encryption salt.

Therefore, storing them allows individual user sessions to be expired. The token system can also be extended to store additional data, such as the device used for logging in. You could then use this information to display all valid sessions and devices in the UI and allow users to explicitly expire any session they deem invalid.

Summary

Functions

build_email_token(user, context, sent_to)

Builds a token and its hash to be delivered to the user's email.

build_token(user, context)

Generates a token that will be stored in a signed place, such as session or cookie. As they are signed, those tokens do not need to be hashed.

changeset(user_token, attrs)

last_used_changeset(user)

Update when the api token was last used by settinglast_used_at.

token_and_context_query(token, context)

Returns the token struct for the given token value and context.

user_and_contexts_query(user, contexts)

Gets all tokens for the given user for the given contexts.

verify_change_email_token_query(token, context)

Checks if the token is valid and returns its underlying lookup query.

verify_email_token_query(token, context)

Checks if the token is valid and returns its underlying lookup query.

verify_token_query(token, context)

Checks if the token is valid and returns its underlying lookup query.

Functions

build_email_token(user, context, sent_to)

Builds a token and its hash to be delivered to the user's email.

The non-hashed token is sent to the user email while the hashed part is stored in the database. The original token cannot be reconstructed, which means anyone with read-only access to the database cannot directly use the token in the application to gain access. Furthermore, if the user changes their email in the system, the tokens sent to the previous email are no longer valid.

Users can easily adapt the existing code to provide other types of delivery methods, for example, by phone numbers.

build_token(user, context)

@spec build_token(Lightning.Accounts.User.t(), context :: binary()) ::
  {binary(),
   Ecto.Changeset.t(%Lightning.Accounts.UserToken{
     __meta__: term(),
     context: term(),
     id: term(),
     inserted_at: term(),
     last_used_at: term(),
     sent_to: term(),
     token: term(),
     user: term(),
     user_id: term()
   })}

Generates a token that will be stored in a signed place, such as session or cookie. As they are signed, those tokens do not need to be hashed.

changeset(user_token, attrs)

last_used_changeset(user)

Update when the api token was last used by settinglast_used_at.

token_and_context_query(token, context)

Returns the token struct for the given token value and context.

user_and_contexts_query(user, contexts)

Gets all tokens for the given user for the given contexts.

verify_change_email_token_query(token, context)

Checks if the token is valid and returns its underlying lookup query.

The query returns the user found by the token, if any.

This is used to validate requests to change the user email. It is different from verify_email_token_query/2 precisely because verify_email_token_query/2 validates the email has not changed, which is the starting point by this function.

The given token is valid if it matches its hashed counterpart in the database and if it has not expired (after @change_email_validity_in_days). The context must always start with "change:".

verify_email_token_query(token, context)

Checks if the token is valid and returns its underlying lookup query.

The query returns the user found by the token, if any.

The given token is valid if it matches its hashed counterpart in the database and the user email has not changed. This function also checks if the token is being used within a certain period, depending on the context. The default contexts supported by this function are either "confirm", for account confirmation emails, and "reset_password", for resetting the password. For verifying requests to change the email, see verify_change_email_token_query/2.

verify_token_query(token, context)

Checks if the token is valid and returns its underlying lookup query.

The query returns the user found by the token, if any.

The token is valid if it matches the value in the database and it has not expired (after @auth_validity_in_seconds or @session_validity_in_days).