small adjustments to phx.gen.auth guide

Author: SteffenDE

guides/authentication/mix_phx_gen_auth.md

@@ -2,7 +2,7 @@
 
 > This guide assumes that you have gone through the [introductory guides](overview.html) and have a Phoenix application [up and running](up_and_running.html).
 
-The `mix phx.gen.auth` command generates a flexible, pre-built authentication system into your Phoenix app. This generator allows you to quickly move past the task of adding authentication to your codebase and stay focused on the real-world problem your application is trying to solve.
+The `mix phx.gen.auth` command generates a flexible, pre-built authentication system based on magic links into your Phoenix app. This generator allows you to quickly move past the task of adding authentication to your codebase and stay focused on the real-world problem your application is trying to solve.
 
 ## Getting started
 
@@ -76,11 +76,10 @@ The generated code ships with an authentication module with a handful of plugs t
 
   * `fetch_current_user` - fetches the current user information if available
   * `require_authenticated_user` - must be invoked after `fetch_current_user` and requires that a current user exists and is authenticated
-  * `redirect_if_user_is_authenticated` - used for the few pages that must not be available to authenticated users
+  * `redirect_if_user_is_authenticated` - used for the few pages that must not be available to authenticated users (only generated for controller based authentication)
+  * `require_sudo_mode` - used for pages that contain sensitive operations and enforces recent authentication
 
-### Confirmation
-
-The generated functionality ships with an account confirmation mechanism, where users have to confirm their account, typically by email. However, the generated code does not forbid users from using the application if their accounts have not yet been confirmed. You can add this functionality by customizing the `require_authenticated_user` in the `Auth` module to check for the `confirmed_at` field (and any other property you desire).
+There are similar `:on_mount` hooks for LiveView based authentication.
 
 ### Notifiers
 
@@ -102,6 +101,10 @@ If your application is sensitive to enumeration attacks, you need to implement y
 
 Furthermore, if you are concerned about enumeration attacks, beware of timing attacks too. For example, registering a new account typically involves additional work (such as writing to the database, sending emails, etc) compared to when an account already exists. Someone could measure the time taken to execute those additional tasks to enumerate emails. This applies to all endpoints (registration, confirmation, password recovery, etc.) that may send email, in-app notifications, etc.
 
+### Confirmation and credential pre-stuffing attacks
+
+The generated functionality ships with an account confirmation mechanism, where users have to confirm their account, typically by email. Furthermore, to prevent security issues, the generated code does forbid users from using the application if their accounts have not yet been confirmed. If you want to change this behavior, please refer to the ["Mixing magic link and password registration" section](Mix.Tasks.Phx.Gen.Auth.html#module-mixing-magic-link-and-password-registration) of `mix phx.gen.auth`.
+
 ### Case sensitiveness
 
 The email lookup is made to be case-insensitive. Case-insensitive lookups are the default in MySQL and MSSQL. In SQLite3 we use [`COLLATE NOCASE`](https://www.sqlite.org/datatype3.html#collating_sequences) in the column definition to support it. In PostgreSQL, we use the [`citext` extension](https://www.postgresql.org/docs/current/citext.html).
@@ -125,6 +128,8 @@ The following links have more information regarding the motivation and design of
   * The [original `phx_gen_auth` repo][phx_gen_auth repo] (for Phoenix 1.5 applications) - This is a great resource to see discussions around decisions that have been made in earlier versions of the project.
   * [Original pull request on bare Phoenix app][auth PR]
   * [Original design spec](https://github.com/dashbitco/mix_phx_gen_auth_demo/blob/auth/README.md)
+  * [Pull request for migrating LiveView based Phoenix 1.7 `phx.gen.auth` to magic links](https://github.com/SteffenDE/phoenix_gen_auth_magic_link/pull/1)
+  * [Pull request for migrating controller based Phoenix 1.7 `phx.gen.auth` to magic links](https://github.com/SteffenDE/phoenix_gen_auth_magic_link/pull/2)
 
 [phx_gen_auth repo]: https://github.com/aaronrenner/phx_gen_auth
 [auth PR]: https://github.com/dashbitco/mix_phx_gen_auth_demo/pull/1

lib/mix/tasks/phx.gen.auth.ex

@@ -26,7 +26,7 @@ defmodule Mix.Tasks.Phx.Gen.Auth do
   to authentication views without necessarily triggering a new HTTP request
   each time (which would result in a full page load).
 
-  ## Security considerations
+  ## Mixing magic link and password registration
 
   `mix phx.gen.auth` generates email based authentication, which assumes the user who
   owns the email address has control over the account. Therefore, it is extremely

priv/templates/phx.gen.auth/context_functions.ex

@@ -213,7 +213,7 @@
 
   3. The <%= schema.singular %> has not confirmed their email but a password is set.
      This cannot happen in the default implementation but may be the
-     source of security pitfalls. See the "Security considerations" section of
+     source of security pitfalls. See the "Mixing magic link and password registration" section of
      `mix help phx.gen.auth`.
   """
   def login_<%= schema.singular %>_by_magic_link(token) do
@@ -227,7 +227,7 @@
 
         This cannot happen with the default implementation, which indicates that you
         might have adapted the code to a different use case. Please make sure to read the
-        "Security considerations" section of `mix help phx.gen.auth`.
+        "Mixing magic link and password registration" section of `mix help phx.gen.auth`.
         """
 
       {%<%= inspect schema.alias %>{confirmed_at: nil} = <%= schema.singular %>, _token} ->