ACCOUNT_EMAIL_CONFIRMATION_HMAC on loadbalanced website

[Michael Schietzsch]

Hi,

I am pretty new to django and allauth. Currently I am trying to figure out how the server will store hmacs for email verification.

If I loadbalacne my site, the key will be stored on this one server? Or will it be stored in the cache? (which would be fine, if I use shared memcached or the like)

Or is it not pissible and I need to switch it off, so allauth will store the keys in the database again?

Thanks

regards

Michael

[Sam Solomon]

Hi Michael,

HMAC is a signing algorithm. It doesn't store anything on the server at all. The information being sent is hashed/signed with a SECRET_KEY, and the info+signature are included in the link (but not the raw SECRET_KEY). This way, when the user clicks on the link, the server can re-hash the info with the SECRET_KEY, and if they match, the server can trust that the message originated from another trusted server (because the signature wouldn't match if the wrong SECRET_KEY was used in the hash of the info).

So in conclusion, this feature will work with a load balanced server cluster without any issues so long as they share the same settings+user database.

Hope that helps,

Sam

--
You received this message because you are subscribed to the Google Groups "django-allauth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-allauth+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Schietzsch]

Hi Sam,

thank you very much for the explanation.  That helps a lot!

Best regards

Michael

Am 25.11.2017 3:48 vorm. schrieb "Sam Solomon" <sss...@gmail.com>:

Hi Michael,

HMAC is a signing algorithm. It doesn't store anything on the server at all. The information being sent is hashed/signed with a SECRET_KEY, and the info+signature are included in the link (but not the raw SECRET_KEY). This way, when the user clicks on the link, the server can re-hash the info with the SECRET_KEY, and if they match, the server can trust that the message originated from another trusted server (because the signature wouldn't match if the wrong SECRET_KEY was used in the hash of the info).

So in conclusion, this feature will work with a load balanced server cluster without any issues so long as they share the same settings+user database.

Hope that helps,

Sam