Can you explain what is a live view’s controller? I haven’t seen it in books.

If I don’t modify this part:

scope "/", PentoWeb do
    pipe_through :browser

    get "/", PageController, :home
  end

,then it means every request to route “/” will be processed by PageController’s “home” action. So PageController is the only controller that I can modify to implement the questions’s redirection. Then I write these codes in page_controller.ex:

defmodule PentoWeb.PageController do
  use PentoWeb, :controller

  def home(conn, _params) do
    if conn.assigns[:current_user] do
      redirect(conn, to: ~p"/guess")
    else
      render(conn, :home, layout: false)
    end
  end
end

I think it’s the answer. And I find that, after redirection, the user has in the same @session_id

I think there are some related and similar concepts:

1. conn.assigns[:current_user] in plugs/controllers, to get the current_user of a conn.

2. plug :fetch_current_user in router.ex “pipeline :browser do”, which adds a key in a conn’s assigns called current_user if the user is logged in

3. socket.assigns.current_user in user_auth.ex on_mount function, which performs authentication for mounting live views inside a live_session.

Notice that the / route isn’t a live view. That means you can’t put it in a live_session block.

Since you’re changing a single view, the easiest way would be to change that view’s behavior in its controller (I see that you’re doing the LiveView book but this is a dead-view problem).

• One way that Phoenix checks if the requesting user is authenticated is to check if conn.assigns[:current_user] is truthy (you can do this in the controller).

• The method used to redirect a dead-view is called redirect. Here’s a link to the relevant docs page: Controllers — Phoenix v1.8.8

Hopefully that’s enough to get you going.

Yeah, that’s how I would do it for a single route.

If there were multiple routes with the same requirement (redirect user to /guess) and you didn’t want to modify each controller, you could do something like this instead:

Modify the scope in the router:

lib/pento_web/router.ex

  scope "/", PentoWeb do
   pipe_through [:browser, :redirect_authenticated_user_to_guess_live]  # this line has changed

    get "/", PageController, :home

    # example route, here for demonstration purposes only:
    # get "/some-other-route", SomeOtherRouteController, :some_route
  end

(The page won’t render until we define the redirect_authenticated_user_to_guess_live/2 function that we referenced in the previous example. Let’s do that now.)

lib/pento_web/user_auth.ex

  def redirect_authenticated_user_to_guess_live(conn, _opts) do
    if conn.assigns[:current_user] do
      redirect(conn, to: "/guess") # redirect the user
    else
      conn # continue the plug pipeline
    end
  end

The page should do the same thing as your original answer without requiring any work in the controller. The logic will apply to any route in that scope.

I’ll try and explain why this works, but I’m also learning, so I’ll probably get this wrong: The reason we can use an atom to reference the function is because:

1. We already imported PentoWeb.UserAuth in the router, so the function is available in the module namespace. (That’s also why the :require_authenticated_user function works. It’s from the same module.)

2. There’s a function somewhere in the router that calls functions based on their names when passed as atoms. I’m not totally sure why, but that’s how it works. On some level, the function names must be exposed as atoms when they are imported.

The router is interesting because it’s one of the first things a new Phoenix developer will see, and yet it is full of some pretty complex functionality. I have faith that there’s a very good reason for how everything is laid out, but my God was it confusing to figure out what was going on there.

It really makes me appreciate the simplicity of Django’s urls.py. But then, Phoenix seems to expose the complexity to you directly, instead of hiding it away like other frameworks, which seems to give you more flexibility in the long run. So the tradeoffs are worth it IMO.