Setting dynamic layouts in LiveViews that correspond with the hostname

Hello everyone.

I have an app that’s going to be setting the layout dynamically according to the current domain name. I’m trying to figure out a way to do it in LiveView.

I’ve gotten to the point where I have an on_mount helper that gets the current hostname and makes it available in assigns, but I’m not able to use that from within the LiveView mount calls, because the helper depends on hooking handle_params. The only other place to set the layout (as far as I know) is in the router or in the myapp_web file where the :live_view helpers are defined, and I’m not seeing how to get access to the hostname from either of those locations.

Is there a recommended way to do this that I’ve missed?

I’m assuming you have a fixed number of subdomains since you probably aren’t going to have an infinite number of layouts :sweat_smile:

There are a few ways to do this. My current project is an online store which has a “retail” layout (for the main domain) and an “admin” layout (for the backoffice admin. subdomain).

I’m currently doing it like this:

In MyAppWeb, ie, in lib/my_app_web.ex I have:

  def admin_live do
    quote do
      use Phoenix.LiveView,
        layout: {MyAppWeb.Layouts, :admin}

      unquote(html_helpers())
    end
  end

  def retail_live do
    quote do
      use Phoenix.LiveView,
        layout: {MyAppWeb.Layouts, :retail}

      unquote(html_helpers())
    end
  end

In lib/my_app_web/components/layouts/ I add an admin.html.heex and retail.html.heex. The :admin in {MyAppWeb.Layouts, :admin}, for example, corresponds to admin.html.heex.

Then in my LiveView, instead of use MyAppWeb, :live_view I do use MyAppWeb, :retail_live and use MyAppWeb, :admin_live.

They do both share the same root layout which is very generic.

I’m happy with my solution but I’d also be interested in hearing how others do this!

Sorry, I think I may have misunderstood what you’re asking. Do you have multiple domains pointing the same LiveView and want the layout to change based on that? In that case I’m not sure it’s possible as I believe the only place to set it is when calling use LiveView, layout: {Mod, :file}. I could be wrong but can’t find anything in the docs and there is this post from José. It’s 2 years old so maybe something’s changed?

There may be a way. What does your router look like?

I’m assuming you have a fixed number of subdomains since you probably aren’t going to have an infinite number of layouts :sweat_smile:

I have a theoretically infinite set of domain names, not just subdomains, to support, but they map to a small, fixed set of themes.

The docs state the layout can be set from the router in the live_session, and from the mount(). I detailed why the mount() approach hasn’t panned out in the OP, and I’m not sure how to get the host information I need into the router to do it from the live_session.

My router right now mostly has the admin routes defined which are exempt from this whole thing. I’ve been working on them while searching for a way to accomplish this. Nothing but a test liveview defined for the public area, and the helpers that I’ve confirmed grab the host and the configuration from my database.

scope "/", MyAppWeb do
    pipe_through [:browser, :do_config]

    # login not required
    ash_authentication_live_session :authenticated_optional,
      on_mount: [
        {MyAppWeb.LiveUserAuth, :live_user_optional},
        {MyAppWeb.AssignUrl, :save_request_uri},
        {MyAppWeb.AssignConfiguration, :assign_configuration}
      ] do

      live "/", PublicLive.Index, :index
    end
    ...
    # other routes
    ...
end

I was using plugs when I had this idea working a while ago in deadviews. The same strategy hasn’t worked in 1.7+ and with LiveViews.

I’m sure there’s some way!

So apart from :temporary_assigns, it looks like mount/3 also accepts a :layout option! So I think you could figure out the layout in your on_mount then grab it from the socket in mount/3 and return it like: {:ok, socket, layout: socket.assigns.layout}. I haven’t actually tried this or anything but that is my best guess. The only thing is that you’ll have to repeat that for every LiveView which probably isn’t the biggest deal.

That’s what I’m currently attempting to do, but it looks like mount/3 happens before handle_params which is where my helper is grabbing the url

defmodule MyAppWeb.AssignUrl do

  def on_mount(:save_request_uri, _params, _session, socket),
    do:
      {:cont,
       Phoenix.LiveView.attach_hook(
         socket,
         :save_request_path,
         :handle_params,
         &save_request_path/3
       )}

  defp save_request_path(_params, url, socket) do
    socket =
      socket
      |> Phoenix.Component.assign(:current_uri, URI.parse(url) |> Map.get(:path))
      |> Phoenix.Component.assign(:current_host, URI.parse(url) |> Map.get(:host))

    {:cont, socket}
  end

So the information I need (the current host) isn’t yet accessible during mount. Unless there’s another way to access it than the current strategy I found here (in a discussion about styling the active nav link)

Can you not set up a plug that puts the host in the session?

2 Likes

Wellllllll shit. Could you add it to the session from a plug so it’s available in mount? Maybe not ideal. I don’t think I can be much help here as I’ve never actually done this myself. I’m interested, though, so hopefully someone else can help!

(and yes, I also read that same thread and how I set the current URL too :slight_smile: )

EDIT: Ha, re: post that beat me to the punch

2 Likes

This actually works! Thank you both! Let me clean it up a bit and make sure I understand it and then I’ll post the full working thing. Are there any downsides or ramifications I should be aware of with regards to storing this in the session? Is this session data modifiable by the user? Going through the docs now

My proof of concept right now is using String.to_atom which i understand comes with some concerns, but layout: demands an atom in Phoenix 1.7+

Session is definitely modifiable by user so if that’s a concern that prob won’t work. It’s further less desirable with String.to_atom as it opens you up to an attack.

The other option here is to use components instead of the layout files. You could load the layout name in handle_params then have a component that delegates to the proper layout component.

attr :name
slot :inner_block
def layout(assigns) do
  ~H"""
  <%= case @name do %>
    <% "admin" -> %><.admin_layout><%= render_slot(@inner_block) %></.admin_layout>
    <% "some_other" -> %><.some_other_layout><%= render_slot(@inner_block) %></.some_other_layout>
    <% ... %>
  <% end %>
  """
end

then in your LiveView:

def render(assigns) do
  ~H"""
  <.layout name={@layout_name_set_in_handle_params}>
    <h1>Hi!</h1>
  </.layout>
  """
end

I would probably pattern match in function heads over that case statement, but you get the gist.

If you were using Surface you could use dynamic components though I’ve never used those so can’t give an example.

EDIT: Just for completeness I meant this as an alternative to the case:

def layout(%{name: "admin"} = assigns) do
  ~H"""
  <.admin_layout>
    <%= render_slot(@inner_block) %>
  </.admin_layout>
  """
end

def layout(%{name: "some_other"} = assigns) do
  ~H"""
  <.some_other_layout>
    <%= render_slot(@inner_block) %>
  </.some_other_layout>
  """
end

And to be clear I meant like they could potentially manipulate the session based on the hostname. If you are whitelisting hostnames then it’s no problem.

Okay…

router.ex

...

  # put host and configuration data into session for retrieval from liveview
  defp sessionify_configuration(conn, _opts) do
    import Plug.Conn

    case MyApp.Sites.Domain.get_by_name(conn.host) do
      {:ok, domain} ->
        configuration =
          domain.site_id
          |> MyApp.Sites.Site.get_by_id!()
          |> MyApp.Sites.load!(:configuration)
          |> Map.get(:configuration)

        conn
        |> put_session(:configuration, configuration)
        |> put_session(:current_host, conn.host)
        |> put_session(:current_path, conn.request_path)

      {:error, error} ->
        IO.inspect(error)
        raise "No Domain found with the name " <> conn.host
        conn
    end
  end

  pipeline :do_config do
    plug :sessionify_configuration
  end

  scope "/", MyAppWeb do
    pipe_through [:browser, :do_config]

    # login not required
    ash_authentication_live_session :authenticated_optional,
      on_mount: [
        {MyAppWeb.LiveUserAuth, :live_user_optional},
        {MyAppWeb.AssignConfiguration, :assign_configuration}
      ] do

      live "/", PublicLive.Index, :index
    end

...

assign_configuration.ex

def on_mount(:assign_configuration, _params, session, socket) do
  socket =
    socket
    |> Phoenix.Component.assign(:configuration, Map.get(session, "configuration"))
    |> Phoenix.Component.assign(:current_host, Map.get(session, "current_host"))
    |> Phoenix.Component.assign(:current_path, Map.get(session, "current_path"))

  {:cont, socket}
end

index.ex

  def mount(_params, _session, socket) do
    socket =
      socket
      |> assign(:page_title, "public")
      |> assign(:testificate, "testificatey")

    layout = {MyAppWeb.Layouts, socket.assigns.configuration.theme}

    {:ok, socket, layout: layout}
  end

This is the flow I have right now that’s working! I was able to remove extraneous hooks and consolidate some functionality into the on_mount. And it looks like Phoenix actually is letting me pass the layout template as a string, too, although it does complain that this is deprecated. So no String.to_atom for now (and if I do have to do that later I think I can just whitelist it based on existing themes).

So the only thing I have to append to every liveview is

layout = {MyAppWeb.Layouts, socket.assigns.configuration.theme}
{:ok, socket, layout: layout}

Not too bad.

And to be clear I meant like they could potentially manipulate the session based on the hostname. If you are whitelisting hostnames then it’s no problem.

This area is all public stuff you can view by simply going to that site, so that should be fine as I understand it. Unless there’s anything drastic I’m missing.

2 Likes

The session is signed by default, so it is not editable by the user. You can also encrypt it to make it impossible for the user to view.

1 Like

Ya, sorry, I clarified I meant if setting session variables based on user input ie if the user spoofs the hostname.

1 Like

Naw you’re good since you’re checking that the domains exist. I was very tired yesterday and answering stuff in a hurry so apologies for any lack of clarity. I was misusing “spoofing” too—I was talking about a worst-case scenario where one would take whatever subdomain is provided, immediately passing it to the session, then calling String.to_atom/1 on it without any kind of checkst. Obviously you are doing none of that so you’re good!