RobertoSchneiders
I’ve been reading about session management on Phoenix LiveView for the last couple of days and can’t seem to find a solution for this problem.
My app is basically entirely built with live views, almost all redirects are live redirects. Most views can be accessed whether you are logged in or not, similar to an e-commerce app. I have a basic authentication system generated by the mix phx.gen.auth. The login is a post HTTP request (so we can set the session cookie).
When a user logs in, ideally, the other tabs that are opened in the same browser would notice that and act accordingly. Another option would be to update the session state of those tabs once the user does an action, e.g. click on a link and navigate to another view. The problem is that everything is a live redirect so the other tabs don’t update the session state unless the user refreshes the page, which is not a great user experience.
Does anyone have any idea on how to solve this?
I’m wondering if it would be possible to force a full page reload on the other tabs when logging in.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
shamanime
You’ve implemented
phx.gen.authso you’re probably aware of the LiveView disconnect when the user logs out. That forces the tabs to reload.If you come up with a way to identify all the tabs which belongs to the same guest user (ip?, browser fingerprint?, setting an identifier in the session at first page load and using it afterwards [like a fake user id]?) and set the
live_socket_idaccordingly, you can also disconnect all the “guest” LiveViews to force a page reload that will fetch the newly signed in user.thomas.fortes
My naive first approach would be something like:
At any new tab check if there’s a token (preferably tamper proof) in local storage and send it to the server, if not, ask for one from the server with an unique identifiable payload (maybe an UUID) and save it in the local storage, in this case only the first page load will actually create a token.
Using on_mount use
attach_hook/4to handle the pushed event with the uuid to subscribe to a “guest#{uuid}” channel and the incominghandle_info/2messages from pubsub.When the user successfully log in you can broadcast a message to the
guest#{uuid}channel that will be handled by thehandle_info/2callback of all liveviews subscribed to that channel.Security considerations aside (short lived tokens, single use, yadda, yadda, yadda) I think someone could build it in a couple hours.
A bit more javascript than I like to write though…
thomas.fortes
Ok, did a proof of concept.
Global hook at app.html.heex
The hook
The module attaching the server hooks
And then just put it in a live session in the router
Then you can call
Phoenix.PubSub.broadcast(Example.PubSub, "reload#1234", [])from anywhere and all pages will redirect to/.Security considerations aside it is pretty simple.
RobertoSchneiders
wow, that was awesome. Thank you both @shamanime @thomas.fortes for your help. The proof of concept was incredibly helpful.
It’s working as expected but I had to change the
subscribe_to_channelfunction to return{:halt, socket}instead of:cont.I’m not sure why but with
:contI was getting an error:I noticed that the
subscribe_to_channelwas being executed and the error would happen after that so I tried the:haltand it worked but, to be honest, I’m not 100% sure why. In your example, Is the event being sent to HomeLive after being processed by thesubscribe_to_channelfunction?thomas.fortes
Had the same error, not in my computer right now but if I recall correctly I used an empty handle event in my liveview (just a catch all handle event that does nothing and just returns
{:noreply, socket})Hermanverschooten
If all your tabs are in the same session, could you not store your channel-id in the session?
Then there is no need for localstorage.
If the tabs are in different sessions, I would not want them to automagically login to this user.
RobertoSchneiders
AFAIK, the session is stored in a cookie by default and live views have no access to it, unless you make an HTTP request, read the session information you want, and then store it somehow in the LiveView.
In my case, I’m not doing any HTTP requests (unless of course, the user refreshes the page) so I can’t really use session information to update the live view states.
Hermanverschooten
To get to your live view initially you have to do a GET request, there in
mount/3you have access to the session. So each tab would have access to the session and use a “token” stored in it to connect to you channel that will them when there was a login.RobertoSchneiders
not quite, because the other tabs already have the liveview mounted, they were opened before the user logged in, so no HTTP requests will be made from that point on.
Hermanverschooten
But when you opened that tab a GET request was issued to your app.