|
5 months ago | |
---|---|---|
db | 6 months ago | |
keys | 7 months ago | |
static | 6 months ago | |
templates | 6 months ago | |
token | 7 months ago | |
.gitignore | 7 months ago | |
README.md | 5 months ago | |
main.go | 6 months ago |
Typically you have a URL that looks like this,
http://yourwebsite.com/confirm-email?token=abcfbcffbabcfcfbbcfaa282bfc8
In your application when request comes in to that URL you grab the token value and check if it is valid by looking up the relevant table in the database.
The table might look like this,
user_id, token, date_generated, date_expires, date_used
1, abcfbcffbabcfcfbbcfaa282bfc8, 2014-03-12, 2014-03-14, NULL
When the link is viewed you must invalidate the corresponding token.
user_id, token, date_generated, date_expires, date_used
1, abcfbcffbabcfcfbbcfaa282bfc8, 2014-03-12, 2014-03-14, 2014-03-13
The token is of course generated randomly at an appropriate time such as after user registration form is submitted.
An alternative approach is to create some sort of deterministic hash using the user data and use that as the token to avoid having to store tokens. But I highly advise against that particularly for more sensitive stuff, sometimes you can get away with that method for a simple "unsubscribe" functionality.
Things to watch out for:
Token must be long (particularly if for pass reset and the like), I'd suggest 24 characters case-sensitive 0-9A-Z
As soon as the link for a token is viewed, it must be marked as used (regardless of the outcome)
Token should have some expiry date, you can adjust this to appropriate value to not annoy users, and depending on the sensitivity of the application, email validation could last 21 days, but pass reset should probably last less than 72 hours.
Be careful to ensure that the token column is unique across the table
https://www.zupzup.org/boltdb-example/ -might be good