Hi

As both a technical reviewer for the book and the author of Ash Authentication this section didn’t jump out at me as wrong - mainly, I suspect, because the memory of all the hoops LiveView forces us to jump through have been suppressed as a self-protection measure.

That said, let’s look at the code:

    # From lib/ash_authentication_phoenix/live_session.ex
    otp_app
    |> AshAuthentication.authenticated_resources()
    |> Stream.map(&{to_string(Info.authentication_subject_name!(&1)), &1})
    |> Enum.reduce(acc, fn {subject_name, resource}, session ->
      case Map.fetch(
             conn.assigns,
             String.to_existing_atom("current_#{subject_name}")
           ) do
        {:ok, user} when is_struct(user, resource) ->
          session
          |> Map.put(subject_name, AshAuthentication.user_to_subject(user))
          |> Map.put("tenant", Ash.PlugHelpers.get_tenant(conn))
          |> Map.put("context", Ash.PlugHelpers.get_context(conn))

        _ ->
          session
          |> Map.put("tenant", Ash.PlugHelpers.get_tenant(conn))
          |> Map.put("context", Ash.PlugHelpers.get_context(conn))
      end
    end)

So you’re right that if there is a current_X assign in the conn then it should be copied into the live session. It also copies what we call the subject (eg user?id=1234) into the session along with the tenant and any extra context.

I think where the confusion comes from is when working with nested live views the session is passed in, but not any of the assigns. This required us to add AshAuthentication.Phoenix.assign_new_resources/2 which can have the side-effect of loading the assigned users from the database if require_token_presence_for_authentication? is set to true.

I guess my answer is “ you’re both right”