Stack Overflow上部署HTTPS：长路尽头（三）

正文

请到「今天看啥」查看全文

对于技术方面，我们现在不必担心*.*.stackexchange.com域的位置。 只要他们在stackexchange.com下，就没问题。 虽然表面上这与HTTPS无关，但它允许我们将诸如meta.gaming.stackexchange.com之类的东西移动到gaming.meta.stackexchange.com，而不会对用户造成任何中断。 这是一个巨人，真是难看的难题。

本地HTTPS开发

为了在这里取得任何进展，本地环境需要尽可能地匹配开发和生产环境。 幸运的是，我们在IIS上，这使得它相当容易实现。 有一个工具，我们用来设置开发环境称为“dev本地设置”，因为我们还是简单的人。 它安装了工具（Visual Studio，git，SSMS等），服务（SQL Server，Redis，Elasticsearch），存储库，数据库，网站和其他一些东西。 我们有基本的工具设置，我们只需要添加SSL/TLS证书。 Core的缩写设置如下所示：

而使用这个的代码，我在这里给出了注释：Register-Websites.psm1。我们通过主机头（在别名中添加它们）设置我们的网站，如果定向，给他们证书（嗯，我们现在应该默认为$ true ...），并授予这些AppPool帐户对数据库的访问权限。好的，现在我们设法在本地开发https://。是的，我知道 - 我们真的应该开源这个设置，但是我们必须以某种方式去掉一些特定于我们的东西。会有那么一天。

为什么这很重要？在此之前，我们从/content中加载静态内容，而不是从另一个域加载。这很方便，但也隐藏了跨原始请求（或CORS）等问题。在同一协议上的同一域上加载的内容可能会很容易在开发和生产中失败。 “它在我的机器上工作。

通过使CDN和应用程序域设置具有与生产相同的协议和布局，我们在离开开发人员的机器之前找到并修复了更多问题。例如，您是否知道从https://页面转到http://时，浏览器不会发送引用者？这是一个安全问题，URL中的敏感位可能会在引用头中通过paintext发送。

“那是胡说，尼克，我们得到Google的引用！”嗯，是的。你得到了。但是那是因为他们明确地选择了。如果您查看Google搜索页面，您会发现这个 指令：

...这就是为什么你从他们那里得到它。

好的，我们设置了一些东西，然后做什么呢？

混合内容：来自用户

这个标签对于具有用户提交内容的网站有很大的影响。 我们多年来积累了什么样的混合内容问题？ 不幸的是，不少。以下是我们必须解决的用户提交内容的列表：

请到「今天看啥」查看全文