tangui
Hi all!
Since I released plug_http_cache, I’ve been asked a few times how to use it to cache LiveView’s initial responses. I’m not very well versed in LiveView, and I think there are many ways one could shoot himself in the foot doing that. However, it seems to be there are some reasonable use-cases for doing that.
One of them is to use http caching to improve SEO ranking for public pages that have little interactivity whether the user is logged in or not. For instance, one LiveView page could render financial charts in real-time as an aside, while the main content is almost static.
I tried plug_http_cache and it almost works out-of-the box:
- initial mount replies with a
200response, which is cached - second mount replies with a
101HTTP response, which is not cacheable. The websocket connection is established
So far so good, but LiveView uses a CSRF token that is cached and sent along the second request - and LiveView WS connection fails when opening the same page in another browser with:
[debug] LiveView session was misconfigured or the user token is outdated.
1) Ensure your session configuration in your endpoint is in a module attribute:
@session_options [
...
]
2) Change the `plug Plug.Session` to use said attribute:
plug Plug.Session, @session_options
3) Also pass the `@session_options` to your LiveView socket:
socket "/live", Phoenix.LiveView.Socket,
websocket: [connect_info: [session: @session_options]]
4) Ensure the `protect_from_forgery` plug is in your router pipeline:
plug :protect_from_forgery
5) Define the CSRF meta tag inside the `<head>` tag in your layout:
<meta name="csrf-token" content={Plug.CSRFProtection.get_csrf_token()} />
6) Pass it forward in your app.js:
let csrfToken = document.querySelector("meta[name='csrf-token']").getAttribute("content");
let liveSocket = new LiveSocket("/live", Socket, {params: {_csrf_token: csrfToken}});
I figured out it’s possible to disable checking of this CSRF token when configuring the live endpoint, at the cost of disabling live sessions:
endpoint.ex before:
socket "/live", Phoenix.LiveView.Socket, websocket: [connect_info: [session: @session_options]]
endpoint.ex after:
socket "/live", Phoenix.LiveView.Socket, websocket: []
My first batch of questions would be:
- is it safe to do so?
- what are the other side-effects, other than disabling live session?
- is that possible to have 2 sockets: one where live sessions are disabled for this specific use-case, and another one with session information enabled?
Another thing I noticed is that some information related to LiveView is stored in the HTML upon initial rendering:
<div
data-phx-main
data-phx-session="SFMyNTY.g2gDaAJhBXQAAAAIdwJpZG0AAAAUcGh4LUY1Q0hZRndnM2I0N0lRSkN3B3Nlc3Npb250AAAAAHcKcGFyZW50X3BpZHcDbmlsdwR2aWV3dy1FbGl4aXIuSHR0cENhY2hlV2l0aExpdmV2aWV3V2ViLlVzZXJMaXZlLlNob3d3BnJvdXRlcncmRWxpeGlyLkh0dHBDYWNoZVdpdGhMaXZldmlld1dlYi5Sb3V0ZXJ3DGxpdmVfc2Vzc2lvbmgCdwdkZWZhdWx0bggAt3Fq2ugnkBd3CHJvb3RfcGlkdwNuaWx3CXJvb3Rfdmlld3ctRWxpeGlyLkh0dHBDYWNoZVdpdGhMaXZldmlld1dlYi5Vc2VyTGl2ZS5TaG93bgYA-_cJWYsBYgABUYA.25eSbZuNO6oxbt4AEcignF3HVsHExGqPcoc8BI8E5nI"
data-phx-static="SFMyNTY.g2gDaAJhBXQAAAADdwJpZG0AAAAUcGh4LUY1Q0hZRndnM2I0N0lRSkN3BWZsYXNodAAAAAB3CmFzc2lnbl9uZXdqbgYA-_cJWYsBYgABUYA.k0KyuD5mMq4arpXYUO2poQAdDrnFipHxVJ1D6B32tyI" id="phx-F5CHYFwg3b47IQJC">
After decoding it, it seems it doesn’t contain private session data, which remains stored in the cookie. However, is there any reason this data shouldn’t be served to users other than the one who initiated the request in the first place?
Lastly, I’d like to write guidance on how to handle authenticated LiveView’s with static content. The idea is to render only public data on initial mount, and load private, session-based data only when the LiveView goes live:
def mount(params, session, socket) do
if not connected?(socket) do
# Initial request: here we render only **public** data.
# The response can be cached by shared caches
products = Products.list(params)
{:ok, assign(socket, products: products)}
else
# Check user authentication
socket =
case session do
%{"user_id" => user_id} ->
assign(socket, user: Accounts.get_user!(user_id))
_ ->
socket
end
# Perform stateful stuff that don't depend on the user
Phoenix.PubSub.subscribe(MyApp.PubSub, "product-updates")
if socket.assigns.user do
# Prepare rendering for authenticated users
socket =
socket
|> assign(:pending_orders, User.get_pending_orders!(socket.assigns.user))
|> assign(:pending_notifications, User.get_pending_notifications(socket.assigns.user))
{:ok, socket}
else
# Prepare rendering for anonymous users
{:ok, socket}
end
end
end
What do you think? Did I miss something? Any security issue I didn’t anticipate?
Cheers!
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
At WyeWorks, we believe great software is built by combining technical excellence with genuine human connection
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 18 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tangui
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.
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.
tangui
The PR has been merged
Thanks to the Phoenix team 
The new option will be available as of Phoenix 1.7.15
I’ve updated the instructions and the demo app.
Happy caching!
tangui
PR created: https://github.com/phoenixframework/phoenix/pull/5952
Feel free to comment, improve the idea.
tangui
Here we go with the second part: Caching Liveviews - Part 2: Publicly caching private Liveviews
(cc @onnimonni )
Happy hacking!
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.
tangui
Unless I’m terribly wrong, this is not the case: only data set via the
:sessionattribute of alive_sessionis 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:
Decoding both values:
There’s no trace of session (cookie) data, only the values set by the
:sessionoption of the live session.LostKobrakai
LV sessions are merged data between what is in the plug/http session store and what is provided by the
:sessionoption 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.tangui
It’s indeed used to store the additional session data set by the
:sessionoption of Phoenix.LiveView.Router.live_session/3. Is this what you are referring to?Or user data from the session? Both will be discussed in the next blog post
LostKobrakai
Afaik the csrf token is not just used to secure the websocket connection against CSWH, but also to sign the session data put into the html. Though I guess if you want to cache html you cannot put per user data on the html anyways. At that point removing the csrf token is indeed viable and should be supported without needing to adjust any of the 3rd party codebases involved - e.g. I did that here: Do not use use a session cookie · LostKobrakai/hex-bobs-list@f86dde5 · GitHub