kuon
When reading about live view, I read this from José:
Why would the login be an horrible idea for LiveView?
And, as a more general question, how should session be managed when using LiveView. For regular app, and API endpoints, I usually just have a require_user plug that check the session for a user_id and retrieve the corresponding user from the database. My login action just |> put_session("user_id", user.id) after a successful login.
How would this work with LiveView?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
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
- #ai
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
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.
Bringing learning, work and compliance together since 1987.
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 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
josevalim
See the original text I was replying to.
If you login through LiveView, then if you navigate to another page or open up another tab, you will have to login again. LiveView keeps the current page state.
When you render a liveview, one of the parameters is the session, which are the session fields currently in your session that you want to send to the liveview.
So if you do:
Then the user_id field will also be available in the LiveView mount, which you can retrieve it from the database once again.
So the idea is to login as usual and then pass the relevant session fields to the live view.
kuon
Right, I get it, this is what I thought at first, but I wasn’t sure.
daveboo
So, I can still build my registration page with liveview, but when signing in, I should just use a normal Phoenix page?
alvises
Yes. If I understood correctly, LiveView can’t update the
:user_idin the session and the LV session is distinct in each browser’s tab.daveboo
Must have been a late night back in May…sorry I didn’t thank you, but this was very helpful, thanks!
why
Would I be mistaken in thinking that the latest version of LiveView (0.5.0-dev) solves this problem?
benwilson512
0.5.0-dev makes the session available but you still can’t edit it.
why
Got it, thanks.
tfwright
If I were set on storing some data about a LV session in the browser session, what would be the best way to do that? Add a vanilla JS link that points to a non-LV controller?
My use-case is that I would like to save some UI state for a returning user even if they don’t login (or have an account).
mindok
@tfwright - did you figure this out?