polypush135
Going off the example auth blog post where we have a plug helper like so.
# lib/my_app/router.ex
import MyAppWeb.UserAuth
pipeline :browser do
...
plug :fetch_current_user
end
# lib/my_app_web/controllers/user_auth.ex
@doc """
Authenticates the user by looking into the session
and remember me token.
"""
def fetch_current_user(conn, _opts) do
{user_token, conn} = ensure_user_token(conn)
user = user_token && Accounts.get_user_by_session_token(user_token)
assign(conn, :current_user, user)
end
In the context of a LiveView module, I see the user_token in the session on the mount callback.
I have seen the notes about sessions being serialized into strings, should I be concerned about upstream pipelines that adds this usrer_token to the session? When inspecting my session values on the mount I see a binary for the user token.
"user_token" => <<..,, ..., ..., ..., >>
Also, I’ve seen the notes about storing the user id vs the whole user value because of the string serialization.
After some reading, it looks like the past way of setting up the session from the route no longer works. Remove deprecate features · phoenixframework/phoenix_live_view@0020c35 · GitHub
My other question is do I just make another plug that sets the session with the user_id for the socket?
if so I assume I then will need to query for the user via the user id every request for LiveView and auth. Is there a better way?
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
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










Showing Posts 1 to 10- Show Best Posts
- Show All Posts (oldest first)
- Show All Posts (newest first)
sfusato
That’s now the default behaviour (all the session is passed and you don’t need to specify the keys):
You could always add a cache for getting the user with a low refresh ttl value.
ChristopheBelpaire
Hello,
I wanted to achieve the same kind of behaviour and be able to access to the current_user in my live view assigns.
The best would be able to assign the current_user to the socket assign, but it doesn’t seems to be possible.
The only way I found to achieve this is to inject a mount function, in live :
It is working, but it is kind of a hack
Is there a better way to achieve this ?
Thanks in advance!
sfusato
It’s what the docs suggest, so definitely not a hack (well, minus the fact that you are doing it in a macro, but other than that it’s the same thing).
polypush135
I’m mostly asking in the context of this post An upcoming authentication solution for Phoenix - Dashbit Blog
So I already have a pipeline that gets a user from a give user token found in the session.
At this point, my first question would be: Should I make a different pipeline for Controllers vs LiveViews?
If I’m already doing a query to look the user up and put that user whole in my assigns via current_user does this still make sense to do, only to add another plug that plucks the user’s ID only just to have to do it all over again on the call to mount?
Seems to me that I would want a different pipeline that calls fetch_current_user_id for LiveView and fetch_current_user for normal controllers. That way I forgo the query for the user in my LiveView till later in the mount where it needs to happen again anyways.
polypush135
That seems to only be true for the first call to mount as the user_token from my session only seems to be available at that time and not the following call to mount.
chrismccord
You need to pull the user_token from the session and fetch the user in the same way the plug pipeline does. You can make use of
assign_newto avoid fetching on the HTTP request, but you need to fallback to fetching on the connected mount, using the same mechanism that the plug pipeline does:To avoid duplication in your LVs, you could pull this out into an
assign_defaultsfunction that you write to wire up common assigns, like current_user. Make sense?polypush135
Still having a little trouble understanding the correct flow.
As stated before I’m working with the same pipeline as the post about auth.
So starting from there my routes look like so.
And I have my view like so.
I can see from my logs that the first call to mount for the HTTP request looks like so.
I can also see from the IO.inspect from the first call to mount which includes a user_token in the session.
I can also see the IO.inspect at the end of the same pipeline I used to assign_new which shows the current_user being set in the assigns as I would expect.
But when it comes to the second call to mount this is where I get a little lost.
Looking at my logs I see the call to js.
Here I don’t see the session nor the prior assigns of current_user.
Also I would have also assumed I should not have directly put the whole current_user into the assigns but rather thought I would need to reconcile the user via user_id.
chrismccord
your second greedy match mount/3 should not be necessary and the fact that you are getting there is definitely the issue. The connected call will include the Plug session , provided you have wired up the session options in your endpoint and csrf token in app.js. Can you post your endpoint? If you are getting here:
Then it makes sense the current_user is not there, because it was never set. The first clause should have matched, so let’s kill the catch-all and figure out why your plug session isn’t being provided.
polypush135
Heres my endpoint.
https://github.com/MorphicPro/morphic.pro/blob/wip/lib/morphic_pro_web/endpoint.ex#L37
And my js
https://github.com/MorphicPro/morphic.pro/blob/wip/assets/js/app.js#L29-L45
Also note this is on my throw away branch
wipjust incase you try to explore other parts of this repo.polypush135
I am seeing a discrepancy between the _csrf_token from the first and second call to the mount. I assume they should be the same for each?
Edit: Ok I think I found the issue in my endpoint.
I was missing
websocket: [connect_info: [session: @session_options]]Edit #2:
Yeah that was it looks like I’m seeing the user_token in the second call to mount now.