To add the confirmation logic, I started a new phoenix application with phauxth (with mix phauxth.new --confirm), which is the openmaize library for Phoenix 1.3, just to see the code and to test it. Then I installed the phauxth package to my ongoing project and replicated the code needed just for the confirmation flow.
I would also include the user-id in the params, and retrieve the record based on that (then check the verify token to confirm or deny) as usually the user_id field will be indexed (resulting in much faster retrieval).
Dockyard (@alexgaribay) has recently published a guide on how to do email verification. It’s similar to the basic flow I stated above, but with leveraging Phoenix.Token as a unique token generator and expiry checking, making it unnecessary to store the token in the DB. I think that’s a really neat and lean approach!
Hi @sawthinkar, the DockYard tutorial article that I shared just above your post outlines how the typical email verification with Phoenix goes (including verify link generation). There’s also a thread about it in this forum:
I got a bit confused on Path Helpers. I was trying to construct the link in html.eex file. It wasn’t properly setup so was getting endpoint errors. I got it now. Thanks!
) has recently published a guide on how to do email verification. It’s similar to the basic flow I stated above, but with leveraging Phoenix.Token as a unique token generator and expiry checking, making it unnecessary to store the token in the DB. I think that’s a really neat and lean approach!
