LostKobrakai

LostKobrakai

LV sessions are merged data between what is in the plug/http session store and what is provided by the :session option on live_session. The merged data is put on the html tags to be sent back by LV. It’s a bit unfortunate that LV calls that data in the html tag session given it’s technically completely unrelated to plug/http level session data.

This basically affects any data you’d get in mount/3s second parameter. So e.g. (not different to http level caching) needing to deal with logged in users would likely require the usage of the session.

0
Post #11
tangui

tangui OP

Unless I’m terribly wrong, this is not the case: only data set via the :session attribute of a live_session is stored in the HTML, and not the session data from the cookie. I have the feeling you assume the websocket connection doesn’t include the cookie, which is wrong - it does. Hence the CSWH issue discussed in the blog post.

Let’s check it out after setting 1) session cookie data 2) setting live_session :default, session: %{"titi" => "toto"} do:

Rendered HTML div root liveview:

<div id="phx-F_F6hHTMdNAciQDC" data-phx-main data-phx-session="SFMyNTY.g2gDaAJhBXQAAAAIdwJpZG0AAAAUcGh4LUZfRjZoSFRNZE5BY2lRREN3B3Nlc3Npb250AAAAAW0AAAAEdGl0aW0AAAAEdG90b3cKcGFyZW50X3BpZHcDbmlsdwZyb3V0ZXJ3I0VsaXhpci5DYWNoZWFibGVMaXZldmlld3NXZWIuUm91dGVydwxsaXZlX3Nlc3Npb25oAncHZGVmYXVsdG4IAIiG5dqDevEXdwR2aWV3dytFbGl4aXIuQ2FjaGVhYmxlTGl2ZXZpZXdzV2ViLk1haW5MaXZlLkluZGV4dwlyb290X3ZpZXd3K0VsaXhpci5DYWNoZWFibGVMaXZldmlld3NXZWIuTWFpbkxpdmUuSW5kZXh3CHJvb3RfcGlkdwNuaWxuBgD5DpazkQFiAAFRgA.mhCxhz3RtfaIh7TRDV1I55h2Ra8h4o5060cFCL_x8RE" data-phx-static="SFMyNTY.g2gDaAJhBXQAAAADdwJpZG0AAAAUcGh4LUZfRjZoSFRNZE5BY2lRREN3BWZsYXNodAAAAAB3CmFzc2lnbl9uZXdqbgYA-g6Ws5EBYgABUYA.M75Zd_M-hrnOsnCrWy15ZFFKwzUJrwkJtX9dXg_iow4"><header class="relative top-0 right-0 left-0 p-1 bg-gray-100">

Decoding both values:

iex(17)> data_phx_session |> String.split(".") |> Enum.map(&Base.url_decode64!(&1, padding: false)) |> Enum.drop(1) |> Enum.take(1) |> Enum.map(&:erlang.binary_to_term/1)
[
  {{5,
    %{
      id: "phx-F_F6hHTMdNAciQDC",
      session: %{"titi" => "toto"},
      parent_pid: nil,
      router: CacheableLiveviewsWeb.Router,
      live_session: {:default, 1725294838991390344},
      view: CacheableLiveviewsWeb.MainLive.Index,
      root_view: CacheableLiveviewsWeb.MainLive.Index,
      root_pid: nil
    }}, 1725294841593, 86400}
]
iex(18)> data_phx_static |> String.split(".") |> Enum.map(&Base.url_decode64!(&1, padding: false)) |> Enum.drop(1) |> Enum.take(1) |> Enum.map(&:erlang.binary_to_term/1)
[
  {{5, %{id: "phx-F_F6hHTMdNAciQDC", flash: %{}, assign_new: []}},
   1725294841594, 86400}
]

There’s no trace of session (cookie) data, only the values set by the :session option of the live session.

1
Post #12
LostKobrakai

LostKobrakai

Seems like I got the actual implementation mixed up with how it works conceptually and what you eventually get in mount/3. But at least in the current implementation of socket you still need a csrf token to get access to the cookie. Iirc earlier versions didn’t allow that at all.

2
Post #13
tangui

tangui OP

PR created: https://github.com/phoenixframework/phoenix/pull/5952

Feel free to comment, improve the idea.

3
Post #15
tangui

tangui OP

The PR has been merged :partying_face: Thanks to the Phoenix team :heart: The new option will be available as of Phoenix 1.7.15

I’ve updated the instructions and the demo app.

Happy caching!

3
Post #16
BartOtten

BartOtten

Nice. I was thinking of a static site generator for the static part so the initial pages can be on a CDN (and socket activated on first interaction?). Seems this lib and the enhancement it brought to the core makes a good base.

0
Post #17
tangui

tangui OP

I guess if you can tell your CDN to browse your sitemap then you can cache your pages this way. I was thinking of warming locally the cache by simulating user requests using something like Invoke Phoenix endpoint programmatically at runtime. Will probably write a blog post about it.

By the way, if you’re using a cloud application platform (Gigalixir, render, fly.io…) and your users are always near one of your servers, then maybe you no longer need a CDN to cache pages. It’d be interesting to make measures and have feedback about it.

0
Post #18
— All posts loaded —