Email confirmation is sending, but confirmation link is not working.
I have a django web app and am using Django Cookiecutter.
My web app is currently https and connected and configured properly to send confirmation emails.
Once a user attempts to sign up the email confirmation gets sent. The email has a link to verify the account, however, the email confirmation link is being sent as http, not https. When I click the email confirmation link, I just get a new tab opened with the link, and a blank white infinite loading screen.
I reached out to Mailgun and they told me everything is fine with the mailgun config. Instead of paraphrasing, here is the direct email response they sent:
I looked into the domain, , and I think I see something that may be causing issues. The domain's HSTS setting is set to 60 seconds. After 60 seconds the domain's HTTP to HTTPS rewrite expires and allows the user to load our tracking links successfully.
At this time Mailgun does not support HSTS nor do we have any workarounds when using HSTS with our tracking features.
If the tracking cookie (anything after /c/ in the URL) wasn't generated by the domain in the URL, the link will not resolve. Previously, we allowed the redirect to occur, which got us into hot water with Google & Norton in the past.
It is extremely important that we do this because a phishing campaign could derail someone like Paypal. Imagine if you crafted a phishing link using a bogus Mailgun domain, then took that rewritten URL cookie and replaced it with "email.paypal.com". It would look super legit, would be serving up a phishing page, and would harm Paypal's reputation.
For customers using HSTS on their domain, it is recommended that they use a different domain with HSTS disabled.
This is a Scenario from one of our Devs:
Say a customer is rewriting HTTPS links through Mailgun, for tracking purposes. If that HTTPS server, for which Mailgun is redirecting to, has HSTS (HTTP Strict Transport Security) enabled, with “includeSubDomains” defined, Chrome will not redirect and instead throw an SSL error. At first, I thought this was a bug in Chrome, because it pre-fetches the redirect… But it turns out the RFC states that if a User Agent is aware of the HSTS preference on the root domain the User Agent should enforce HSTS until the TTL expires. Solution? There is none. Unless they want to remove “includeSubDomains” and let the TTL expire. Here’s what the header looks like on a host with HSTS enabled:
Strict-Transport-Security: max-age=31536000; includeSubDomains
This is being handled by Django allauth. They supposedly have an option to set the activation_url to be https by overriding the ACCOUNT_DEFAULT_HTTP_PROTOCOL. The specifics allauth docs for this setting can be seen here.
I have followed the suggested instructions and set:
ACCOUNT_DEFAULT_HTTP_PROTOCOL = "https" in my settings. That didn't work, I tried it in my .env file and included the variable in my settings also. Tried setting an environment variable as suggested in this StackOverflow post that was "solved" a few years ago. However it seems the code has changed.
If I can provide anymore details I would be happy to do so -- just let me know.
Another thing worth mentioning is that I can get the email confirmation to work if I remove the following setting:
SECURE_HSTS_INCLUDE_SUBDOMAINS = env.bool(
'DJANGO_SECURE_HSTS_INCLUDE_SUBDOMAINS', default=True
from my production settings.py, however from my understanding that would be a security hole and I obviously don't want to do that.
