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”