Chapter 5: Authentication: Who Are You? (107)

Introducing AshAuthentication
    There is 2 part to Authentication for ASH, the core ash_authentication and then the ash_authentication_phoenix. For this chapter we will just be letting the ash installer do most of the work but will be going over each step as is needed. First lets get the right Igniter to install the ash_authentication
        mix igniter.install ash_authentication

    New Domain, Who's This?
        So as before we were working with domains and we had Tunez.Music, Authentication is an other type here that will be used to deal with the users. We just made Tunez.Accounts that will have 2 resources, Tunez.Accounts.User and Tunez.Accounts.Token

        Tunez.Accounts.User in lib/tunez/accounts/user.ex is for the Users that we will make and deal with. There is also a DB setup for users in the users database, it doesn't have much at the moment besides ID, and some boilerplate for the configuration

    Tokens and Secrets and Config, Oh My!
        Tokens, via Tunez.Accounts.Token resource are the secret sauce for AshAuthentication. This is how we will identify a user. They will be provided upon request for every session that a user will need. It should be good right out the box but there are ways to change settings, in the mean time the only thing we need to do now to make this all work is to set up a strategy for the Authentication.

Setting Up Password Authentication
    The normal way that most people will use Authentication is to set up a password and user name and then enter those in-order to access the website. There are other ways of doing this like; OAuth and magic links but we will use the password strategy for this site. It is a simple command line to take care of this. This will add in these bits of code:
        2 new attributes for Tunez.Accounts.User email and hashed_password
        Strategies block added to Authentication config in Tunez.Accounts.User resource
        confirmation add-on added to the add_ons block as part of authentication config in Tunez.Accounts.User, this will require the user to authenticate their emails.
        A whole set of actions in Tunez.Accounts.Users for signing in. 
        2 modules to handle sending email confirmations, and password reset.

        mix ash_authentication.add_strategy password 

    With the mix done you will now need to mix ash.migrate to set up the new repo and db
        mix ash.migrate

    Testing Authentication Actions in iex
        One of the actions that we created with the generator is create:register_with_password action. This should take an: email, password, and password_confirmation and creates a user record. Lets test it out.
            iex -S mix
            iex(1)> Tunez.Accounts.User
            Tunez.Accounts.User                
            iex(2)> |> Ash.Changeset.for_create(:register_with_password, %{email: <<email>>, password: "supersecret", password_confirmation: "supersecret"})
            #Ash.Changeset<
            domain: Tunez.Accounts,
            action_type: :create,
            action: :register_with_password,
            attributes: %{email: #Ash.CiString<"***email***">},
            relationships: %{},
            arguments: %{
                password: "**redacted**",
                email: #Ash.CiString<"***email***">,
                password_confirmation: "**redacted**"
            },
            errors: [],
            data: %Tunez.Accounts.User{
                id: nil,
                email: nil,
                confirmed_at: nil,
                __meta__: #Ecto.Schema.Metadata<:built, "users">
            },
            valid?: true
            >
            iex(3)> |> Ash.create!(authorize?: false)
            [debug] QUERY OK db=0.3ms idle=527.3ms
            begin []

        This did a few things added a new user into the db, created a token for the user to authenticate and confirm their email, generated an email that will be sent out (This wont be done in dev but all the pluming will be there for it.) Now what can we do with this?  Lets try to authenticate with a faux form to do so.
            iex(1)> Tunez.Accounts.User
            Tunez.Accounts.User
            iex(2)> |> Ash.Query.for_read(:sign_in_with_password, %{email: "***email***", password: "supersecret"})
            #Ash.Query<
            resource: Tunez.Accounts.User,
            action: :sign_in_with_password,
            arguments: %{
                password: "**redacted**",
                email: #Ash.CiString<"***email***">
            },
            filter: #Ash.Filter<email == #Ash.CiString<"***email***"> and not  is_nil(hashed_password) == "**redacted**">
            >
            iex(3)> |> Ash.read(authorize?: false)
            [debug] QUERY OK source="users" db=1.9ms decode=1.6ms queue=0.8ms idle=765.6ms
            SELECT u0."id", u0."email", u0."confirmed_at", u0."hashed_password" FROM "users" AS u0 WHERE (u0."email"::citext = ($1::citext)::citext) AND (NOT (u0."hashed_password"::text IS NULL)) ...
            ↳ AshPostgres.DataLayer.bulk_create/3, at: lib/data_layer.ex:2024
            {:ok,
            [
            %Tunez.Accounts.User{
                id: "cd36f5a7-9f3e-460b-bd45-cdc92367dbfe",
                email: #Ash.CiString<"***email***">,
                confirmed_at: nil,
                __meta__: #Ecto.Schema.Metadata<:loaded, "users">
            }
            ]}

        Don't forget each line but you should have the user in the db and then you should be able to find the user with these commands. You can even check the token for the user with the right permissions.
            iex(4)> {:ok, [user]} = v()
            {:ok,
            [
            %Tunez.Accounts.User{
                id: "cd36f5a7-9f3e-460b-bd45-cdc92367dbfe",
                email: #Ash.CiString<"***email***">,
                confirmed_at: nil,
                __meta__: #Ecto.Schema.Metadata<:loaded, "users">
            }
            ]}
            iex(5)> user.__metadata__.token
            "eyJhbGciOiJIUzI1NiIsInR5cCI6Ik..."

        Now lets test out the verification by use the JSON Wet Token (JWT)
            iex(6)> AshAuthentication.Jwt.verify(user.__metadata__.token, :tunez)
            [debug] QUERY OK source="tokens" db=0.5ms queue=0.6ms idle=1175.7ms
            SELECT TRUE FROM "tokens" AS t0 WHERE (t0."purpose"::text = $1::text) AND (t0."jti"::text = $2::text) LIMIT 1 ...
            "purpose" => "user",
            "sub" => "user?id=cd36f5a7-9f3e-460b-bd45-cdc92367dbfe"
            }, Tunez.Accounts.User}

        The interesting part is the purpose and the sub, you can use a JWY's for a variety of reasons for this case we are verifying a user. Now that we have the JWT we can see if a user is using the right JWT and their token.
            iex(15)> {:ok, claims, resource} = v()
            {:ok, %{...}, Tunez.Accounts.User}
            iex(16)> AshAuthentication.subject_to_user(claims["sub"], resource)
            SELECT u0."id", u0."confirmed_at", u0."hashed_password", u0."email" FROM
            "users" AS u0 WHERE (u0."id"::uuid::uuid = $1::uuid::uuid) [«uuid»]
            {:ok, %Tunez.Accounts.User{email: #Ash.CiString<«your email»>, ...}}

        You don't need to worry about all of this but again a user will log in and then receive a token that will work for only them.

Automatic UIs with AshAuthenticationPhoenix
    Now that we have a way to create a user and then get their token we need a UI for that. We will not use an other igniter to get this done, the command is below and it will:
        Set the config file in .igniter.exs this is the first generator that needs a specific configuration
        TunezWeb.AuthOverrides module that will customize the look, see (lib/tunez_web/auth_overrides.ex)
        TunezWeb.AuthController module to securely process sign-in requests. (in lib/tunez_web/controller)
        TunezWeb.LiveUserAuth module providing a set of hooks we can use in live-views (lib/tunez_web/live_user_auth.ex)
        updates our router to handle the new plugs and routes (lib/tunez_web/router.ex)
        mix igniter.install ash_authentication_phoenix

    Okay that is all taken care of but as of right now Igniter doesn't know how to patch JavaScript or CSS files. We need to add Tailwinds live-view paths to the assets. Head to /assets/css/app.css and add in this line
        /* ... */
        @source "../../lib/tunez_web";
        @source "../../deps/ash_authentication_phoenix";

        @plugin "@tailwindcss/forms";
        /* ... */

    Now you can head to /sign-in to see the login page. You can create a user (try the one you already made) you will then be redirected to the home page, we will not work on making it look like you are logged in.

    Showing the Currently Authenticated User
        It is normal for it to show the current user in the top right so let's do that now. Head to lib/tunez_web/components/layouts.ex and lets add in a line to show the current user.
            <div class="flex items-center w-full p-4 pb-2 border-b-2 border-primary-600">
                <div class="flex-1 mr-4">
                    <% # ... %>
                </div>
                <.user_info current_user={@current_user} socket={@socket} />
            </div>

        Now we have the line that will show the current user but its not public and we now need to dig into why its not showing the current user.

        "Digging into AshAuthenticationPhoenix's Generated Router Code"
            Most everything the generator did is perfect but there are a few things that it didn't do for us. It set up some pipelines for load_from_bearer, and load_from_session, these are for the JWT and are able to load the record for the user. But live-view works differently we need to find a way to get the session info into the current session as live-view knows that they are authenticated but not the session that was created for the user. 

            This is where live_session comes in. It's wrapped in ash with AshAuthentication, ash_authentication_live_session, this will make sure that when new sessions are spawned they will have the correct data and will still be secure. So for Tunez we need to make sure that the routes that need to be logged in will be in the ash_authentication_live_session block. so these first routes need to be moved into the correct block. lib/tunez_web/router.ex
                scope "/", TunezWeb do
                    pipe_through :browser
                    # This is the block of routes to move
                    live "/", Artists.IndexLive
                    # ...
                    live "/albums/:id/edit", Albums.FormLive, :edit
                    auth_routes AuthController, Tunez.Accounts.User, path: "/auth"
                    # ...
                    # will be moved to this should be higher up in the block of code.

                scope "/", TunezWeb do
                    pipe_through :browser
                    ash_authentication_live_session :authenticated_routes do
                    # This is the location that the block of routes should be moved to
                    live "/", Artists.IndexLive
                    # ...
                    live "/albums/:id/edit", Albums.FormLive, :edit
                    end
                end

    Stylin' and Profilin' with AuthOverrides
        There is a file that was created to change some of the standard components class names and url images etc. Let's head to lib/tunez_web/auth_overrides.ex. It can be hard to figure out exactly what we want to override here. To maybe help the submit button is an input. Let's override the input component. Within the file you will see some syntax for doing some of the overrides. 
            # add this into the file
            override AshAuthentication.Phoenix.Components.Password.Input do
                set :submit_class, "bg-primary-600 text-white my-4 py-3 px-5 text-sm"
            end

        There it is the button is now purple, keep in mind that anything you do here you will change for every instance of the component. They provided a set of overrides in lib/tunez_web/auth_overrides_sample.txt but if don't see it here it is for you.
            alias AshAuthentication.Phoenix.Components

            override Components.Banner do
                set :image_url, nil
                set :dark_image_url, nil
                set :text_class, "text-8xl text-accent-400"
                set :text, "♫"
            end

            override Components.Password do
                set :toggler_class, "flex-none text-primary-600 px-2 first:pl-0 last:pr-0"
            end

            override Components.Password.Input do
                set :field_class, "mt-4"
                set :label_class, "block text-sm font-medium leading-6 text-zinc-800"
                set :input_class, TunezWeb.CoreComponents.form_input_styles()

                set :input_class_with_error, [
                    TunezWeb.CoreComponents.form_input_styles(),
                    "!border-error-400 focus:!border-error-600 focus:!ring-error-100"
                ]

                set :submit_class, [
                    "phx-submit-loading:opacity-75 my-4 py-3 px-5 text-sm",
                    "bg-primary-600 hover:bg-primary-700 text-white",
                    "rounded-lg font-medium leading-none cursor-pointer"
                ]

                set :error_ul, "mt-2 flex gap-2 text-sm leading-6 text-error-600"
            end

            override Components.MagicLink do
                set :request_flash_text, "Check your email for a sign-in link!"
            end

            override Components.MagicLink.Input do
                set :submit_class, [
                    "phx-submit-loading:opacity-75 my-8 mx-auto py-3 px-5 text-sm",
                    "bg-primary-600 hover:bg-primary-700 text-white",
                    "rounded-lg font-medium leading-none block cursor-pointer"
                ]
            end

            override Components.Confirm.Input do
                set :submit_class, [
                    "phx-submit-loading:opacity-75 my-8 mx-auto py-3 px-5 text-sm",
                    "bg-primary-600 hover:bg-primary-700 text-white",
                    "rounded-lg font-medium leading-none block cursor-pointer"
                ]
            end

    Why Do Users Always Forget Their Passwords!?
        When we did the initial setup for AshAuthentication we did 2 things (senders) that will send emails for confirmation and password reset. SendNewUser ConfirmationEmail SendPasswordResetEmail.

        Phoenix apps come with Swoosh that is designed for sending emails. Each sender function does two things: body/1 (generates content) and send/3 that is for constructing and sending the email. There is going to need a email provider to send the emails. However during production you will need to have a place to hold those emails, it will be at http://localhost:4000/dev/mailbox. 

Setting Up Magic Link Authentication
    Nowadays there is ways to setup some magic links that will just be sent to a user in order to just use the link to log-in. Ash has this in the box. Lets try the magic link method. With the command below it will do the following:
        Add a new magic_link authentication strategy to the Tunez.Accounts.User resource, lib/tunez/accounts/user.ex
        Add to new actions sign_in_with_magic_link and request_magic_link in Tunez.Accounts.User resource.
        Remove allow_nil? false, on the hashed_password in Tunez.Accounts.User resource.
        Add a new sender module responsible for generating the magic link email, in lib/tunez/accounts/user/senders/send_magic_link_email.ex
        mix ash_authentication.add_strategy magic_link

        Then as always migrate
        mix ash.migrate

    Boom We now have the 2 options.

    Debugging When Authentication Goes Wrong
        We might need to debug, with more robust error messages during dev. In order to do that we can head to /config/dev.exs and add this to the bottom.
            config :ash_authentication, debug_authentication_failures?: true

        Restart the server and head to the same magic link and you should see more within the error log, what is it telling you is that the link has already been used. Without the robust logging you might never be able to understand what is happening. 

    Can We Allow Authentication over Our API?
        We can even do all of this over API, First let's set up the command then we can start to lock down the paths over api.
            mix ash.extend Tunez.Accounts.User json_api

        This made is sure that we have some new actions and then we need to add in a new route with the action register_with_password action. Head to lib/tunez/accounts.ex
            defmodule Tunez.Accounts do
                use Ash.Domain, otp_app: :tunez, extensions: [AshJsonApi.Domain]

                json_api do
                    routes do
                    base_route "/users", Tunez.Accounts.User do
                        post(:register_with_password, route: "/register")
                    end
                    end
                end

                # ...
            end

        Okay so we have the new route and much more but at the time we can't use the API as there is too much locked down and we don't want people to change peoples password as the API could allow people to do that.