电子邮件确认正在发送，但确认链接无效。
我有一个django网络应用程序，正在使用Django Cookiecutter。
我的网络应用目前正在https，已正确连接并配置为发送确认电子邮件。
一旦用户尝试注册，电子邮件确认就会被发送。电子邮件中有一个用于验证帐户的链接，但是，电子邮件确认链接是以http发送的，而不是https。当我点击电子邮件确认链接时，我只是打开了一个带有链接的新选项卡，以及一个空白的无限加载屏幕。
我联系了Mailgun，他们告诉我mailgun配置一切正常。而不是释义，这是他们发送的直接电子邮件回复：
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
这是由Django allauth处理的。他们应该可以选择通过覆盖ACCOUNT_DEFAULT_HTTP_PROTOCOL将activation_url设置为https。可以看到此设置的详细信息allauth doc here。
我已遵循建议的说明并设置：
我的设置中ACCOUNT_DEFAULT_HTTP_PROTOCOL = "https"。这不起作用，我在我的.env文件中尝试了它，并在我的设置中也包含了变量。试图设置一个环境变量，如this StackOverflow post中建议的那样，已经解决了＃34;几年前。但是，代码似乎已经改变了。
如果我能提供更多细节，我很乐意这样做 - 请告诉我。
另一件值得一提的是，如果删除以下设置，我可以收到确认电子邮件：
SECURE_HSTS_INCLUDE_SUBDOMAINS = env.bool(
'DJANGO_SECURE_HSTS_INCLUDE_SUBDOMAINS', default=True
从我的生产settings.py，然而从我的理解，这将是一个安全漏洞，我显然不想这样做。