Got it.
thojanssens1
LostKobrakai
I’m not aware of any timeout feature in mnesia as well and ETS would mean you’ll lose your tokens if the machine stops (e.g. deployment) as well as the data not being shared between machines. Usually you’ll just periodically cleanup such tables by removing everything already expired. It often doesn’t matter if there are a bunch of recently expired tokens still in the db.
0
wolfiton
OK, because in node from where i come from that was the method used to handle this scenarios.
I would use it like this:
-
User creates account then:
-
a function generates the token and stores it in redis like this {account_conf_token: “token”}
-
another functions create a link with the token
-
nodemailer send confirmation email with the link generated with token towards user
-
the user clicks the link in the email and makes a request
-
the request is handled by another function that validates the token if it is valid then delete the token from redis and update the user account to confirmed
else the user gets an error of unauthorized or page not found.
This process repeats for the forgot password scenario.
The token can be used only once
0
wolfiton
Also redis would remember the last modifications when the server is restarted, I don’t know how but i have to look into it.
There is an option for redis to write to disk before server shutdown
0
wolfiton
LostKobrakai
ETS is not persistent (memory only), mnesia/dets is. But why introduce the complexity of another storage if you’re already using ecto. You used redis before, but what was the reason for another storage in the first place?
The workflow you posted above will be exactly the same with elixir. I’m not questioning the flow, but the choice of storage. Also keep in mind that even no storage is an option. E.g. you could use Phoenix.Token for the tokens, which you can validate at a later time without having something stored.
0
wolfiton
The idea was for performance. To write and delete from redis is faster then from mongodb or postresql when it comes to node applications.
What would I do when I want to delete the token after i use it for that particular request(account_confirm or forgot_password). If I use Phoenix tokens?
Because in node I used this strategy to be able to get rid of tokens that were already used, but by using Phoenix Token i would have to wait for that token to expire.
So how would I handle the scenario were a malicious users makes multiple requests using the same link with the token that hasn’t expired yet?
0
wolfiton
Thanks @LostKobrakai for your thoughts and the idea exchange on this topic.
Also waiting for others to join this discussion and bring some ideas or experiences into it.
0
LostKobrakai
Fair enough. I’d first validate that ecto is indeed not fast enough, which depends a lot on your setup and numbers of registration per timeframe. If so mnesia or redis can still be useful.
There’s no deletion, because there’s no storage (besides what you sent the user). But do you care? Usually confirmation of an email address is idempotent. You can confirm it once, twice, however often, the result will always be the same. Unless it’s ddos level amounts of requests (different topic) it should be fine to just let users confirm their emails multiple times.
0
OvermindDL1
For now, storing IPs in sessions is irritating, when on my phone I change my IP a lot, even mid transactions.
Cachex for Elixir is even faster. Redis is useless unless multiple languages are using it.
4