强制HTTPS特定网址 [英] Force HTTPS for specific URL

问题描述

这应该是一个快速...这里是我目前的.htaccess文件：

This should be a quick one... here is my current .htaccess file:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

我需要做的是确保如果 http://www.mydomain.com/cart/ 达成，它需要强制HTTPS ...等等 /车/ ，并在任何 /车/

What I need to do is make sure that if http://www.mydomain.com/cart/ is reached, it needs to force HTTPS ... so /cart/ and anything within /cart/

推荐答案

一旦请求已发送到 http://www.mydomain.com/cart/ ，如果有任何敏感数据的请求时，为时已晚。迫使它打破！至少，它会给你一个迹象表明有什么东西不对您的链接。在previous答案详细信息：

Once the request has been sent to http://www.mydomain.com/cart/, if there is any sensitive data in the request, it's too late. Force it to break! At least, it will give you an indication that there's something wrong with your links. More details in previous answers:

• http://stackoverflow.com/a/8765067/372643
• http://stackoverflow.com/a/8964190/372643

• http://stackoverflow.com/a/8765067/372643
• http://stackoverflow.com/a/8964190/372643

[...]的请求到达服务器的时间，   太晚了。如果有一个中间人，他做了他的攻击（或部分   它），你得到了请求之前。

[ ... ] by the time the request reaches the server, it's too late. If there is a MITM, he has done his attack (or part of it) before you got the request.

您可以通过然后做最好的是没有任何有用的内容回复。在   这种情况下，一个重定向（使用301或302和Location头）   可能是适当的。但是，它可能隐藏的问题，如果用户（或   即使你作为一个开发人员）忽略警告（在这种情况下，   浏览器将遵循重定向和重试请求几乎   透明的）。

The best you can do by then is to reply without any useful content. In this case, a redirection (using 301 or 302 and the Location header) could be appropriate. However, it may hide problems if the user (or even you as a developer) ignores the warnings (in this case, the browser will follow the redirection and retry the request almost transparently).

所以，我只是建议返回404状态：

Therefore, I would simply suggest returning a 404 status:

  
• 的http：// yoursite / 和的https：// yoursite / 是有效的两个不同的网站。没有理由期待一个1：1的映射所有   从URI空间资源从一个到另一个（只是在相同的   因为你可以有一个完全不同的层次结构方式   的ftp：// yoursite / ）
  
• 更重要的是，这是应该的上游处理一个问题：导致你的用户使用这种资源的链接的http：//   应考虑为已损坏。不要让它自动工作。   有一个404状态的资源不应该有罚款。在   此外，返回一条错误消息时，出现错误是好的：   它会迫使你（或至少是提醒你），作为一个开发人员，你   需要修复的页/表格/链接，导致了这个问题。
  

• http://yoursite/ and https://yoursite/ are effectively two distinct sites. There is no reason to expect a 1:1 mapping of all resources from the URI spaces from one to the other (just in the same way as you could have a completely different hierarchy for ftp://yoursite/).
• More importantly, this is a problem that should be treated upstream: the link that led your user to this resource using http:// should be considered as broken. Don't make it work automatically. Having a 404 status for a resource that shouldn't be there is fine. In addition, returning an error message when there is an error is good: it will force you (or at least remind you) as a developer that you need to fix the page/form/link that led to this problem.

编辑：（例）

让我们假设你有 http://example.com/ ，您的网站的非安全部分，允许用户浏览的项目。他们不是在这个阶段登录的，所以它的细做它通过纯HTTP。

Let's say you have http://example.com/, the non-secure section of your site that allows the user to browse items. They're not logged in at that stage, so it's fine to do it over plain HTTP.

现在，它的车/付款时间。你想HTTPS。您向用户发送 https://example.com/cart/ 。如果是使用普通的HTTP将用户购物车的部分（即 http://example.com/cart/ ）的链接之一，这是一个发展的错误。它只是不应该存在。制作的过程中休息时，你以为你会被发送到 https://example.com/cart/ 允许开发人员看到它（和，一旦固定的，用户不应该有问题）。

Now, it's cart/payment time. You want HTTPS. You send the user to https://example.com/cart/. If one of the links that sends the user to the cart part is using plain HTTP (i.e. http://example.com/cart/), it's a development mistake. It just shouldn't be there. Making the process break when you thought you were going to be sent to https://example.com/cart/ allows the developer to see it (and, once fixed, the user should never have the problem).

如果它只是（通过地方的链接通常情况下，一个HTTP GET），点到你的网站的HTTPS部分，它不一定那么大的风险。

If it's just about the point to the HTTPS section of your site (typically, an HTTP GET via a link somewhere), it's not necessarily that big a risk.

当自动重定向变得更加危险的是，当他们隐藏更大的问题。

Where automatic redirects become even more dangerous is when they hide bigger problems.

例如，你在 https://example.com/cart/creditcarddetails 和你填写一些信息，确实应该仅仅停留在SSL上。然而，开发者已经犯了一个错误和一个普通的的http：// 链接的形式使用。此外，开发者（用户/人毕竟）点击了在Firefox中不再显示此消息时，它说：警告：你从一个安全的页面将非安全页（顺便说一下，不幸的是，火狐警告后验：它已经作出的不安全请求的时候它显示了用户该消息）。现在，随着敏感数据GET / POST请求首先被送到不正确的纯的http：// 链接和自动重写告诉浏览器重新尝试请求了的https：// 。它看起来很好，因为，就用户而言，这一切都发生在一秒钟的时间。但是，它不是：。敏感数据被发送明文

For example, you're on https://example.com/cart/creditcarddetails and you've filled in some information that should really just stay over SSL. However, the developer has made a mistake and a plain http:// link is used in the form. In addition, the developer (a user/human after all) has clicked on "don't show me this message again" in Firefox when it says "Warning: you're going from a secure page to a non-secure page" (by the way, unfortunately, Firefox warns a posteriori: it has already made the insecure request by the time it shows the user that message). Now, that GET/POST request with sensitive data is sent first to that incorrect plain http:// link and the automatic rewrites tells the browser to try the request again over https://. It looks fine because, as far as the user is concerned, this all happened in a fraction of a second. However, it's not: sensitive data was sent in clear.

制作的东西只应通过HTTPS不做任何有用的纯HTTP部分实际上有助于你看看什么是错的更清楚。因为用户不应该在那里结束反正如果链接的正确实施，这是不是一个真正的问题他们。

Making the plain HTTP section of what should only be over HTTPS not do anything useful actually helps you see what's wrong more clearly. Since the users should never end up there anyway if the links are correctly implemented, this isn't really an issue for them.

这篇关于强制HTTPS特定网址的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！