If I was storing current_user in the assigns how hard would it be for a hacker to fake that assigns?
Should I do more to assure the assigns is valid?
For example I was reading this auth library example for phoenix
One thing that I don’t like about this pattern is that it expects that you pass the user’s id as a request param and then it compares it to the current_user in the assigns as an extra layer of authorization.
I don’t want to expose the user’s id if I can avoid it so I wonder if this is even necessary
if I can trust my assigns in my plug then I can just lock that user to only even being able to load the user from the assigns alone.
Thus not needing to expose their ID via the params which I feel is a greater risk because of the higher likelihood a hacker would try to use it via a sql injection but, that assumes I can trust my assigns. If I can’t then this makes more sense and in that case I may be better off migrating my ids to UUID for users if only to obscure that vector attempt
You can fully trust the assigns, as it only exist serverside. It does not survive a request though, so you need something in the session to repopulate your assigns in subsequent authorized requests.
Also something else that has come to my attention is that I at the end of the day I really need to trust my pipeline if I want to trust my plug and I think that is really the big take a way for me.
The question was more around if someone can fake data in the assigns. IE is the current_user in my plug assigns trustworthy or should I do more to vet that value?
From what I learned the only way you edit the assigns is via plug. So that said it should be noted that you can only trust your assigns as well as you can trust your pipeline (including your hex packages that add to it)
