Это должно быть быстрым... вот мой текущий файл .htaccess:
# 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... так /cart/ и что-нибудь в /cart/
Как только запрос отправлен на http://www.mydomain.com/cart/, если в запросе есть какие-либо конфиденциальные данные, это слишком поздно. Заставьте его сломаться! По крайней мере, это даст вам указание, что с вашими ссылками что-то не так. Более подробно в предыдущих ответах:
[...] к моменту поступления запроса на сервер, это слишком поздно. Если есть MITM, он совершил свою атаку (или часть это), прежде чем вы получите запрос.
Лучшее, что вы можете сделать к тому времени, - ответить без какого-либо полезного контента. В этот случай, перенаправление (с использованием 301 или 302 и заголовка местоположения) может быть уместным. Однако это может скрыть проблемы, если пользователь (или даже вы как разработчик) игнорирует предупреждения (в этом случае браузер выполнит перенаправление и повторит запрос почти прозрачно).
Поэтому я просто предлагаю вернуть статус 404:
http://yoursite/иhttps://yoursite/являются фактически двумя разными сайтами. Нет причин ожидать отображения 1:1 всех ресурсы из пространства URI от одного к другому (только в том же так как у вас может быть совершенно другая иерархия дляftp://yoursite/).- Что еще более важно, это проблема, с которой следует обращаться вверх по течению: ссылка, которая привела вашего пользователя к этому ресурсу с помощью
http://следует считать сломанным. Не заставляйте его работать автоматически. Наличие статуса 404 для ресурса, который не должен быть там, прекрасен. В добавление, возврат сообщения об ошибке при наличии ошибки: это заставит вас (или, по крайней мере, напомнить вам), как разработчика, что вы необходимо исправить страницу/форму/ссылку, которые привели к этой проблеме.
EDIT: (пример)
Скажем, у вас есть http://example.com/, незащищенный раздел вашего сайта, который позволяет пользователю просматривать элементы. Они не вошли в систему на этом этапе, так что это нормально, чтобы сделать это через простой HTTP.
Теперь, это время перевозки/оплаты. Вы хотите HTTPS. Вы отправляете пользователя на https://example.com/cart/. Если одна из ссылок, которая отправляет пользователя в корзину, использует простой HTTP (т.е. http://example.com/cart/), это ошибка разработки. Его просто не должно быть. Прерывание процесса, когда вы считаете, что вас отправят на https://example.com/cart/, позволяет разработчику увидеть его (и, как только исправлено, у пользователя никогда не будет проблемы).
Если речь идет только о разделе HTTPS вашего сайта (как правило, HTTP GET через ссылку где-то), это не обязательно будет большим риском.
Если автоматическое перенаправление становится еще более опасным, это когда они скрывают большие проблемы.
Например, вы находитесь на https://example.com/cart/creditcarddetails, и вы заполнили некоторую информацию, которая должна действительно просто оставаться над SSL. Однако разработчик допустил ошибку, и в форме используется простая ссылка http://. Кроме того, разработчик (в конце концов, пользователь/человек) нажал "не показывать мне это сообщение снова" в Firefox, когда он говорит "Предупреждение: вы переходите с защищенной страницы на незащищенную страницу" ( Кстати, к сожалению, Firefox предупреждает апостериор: он уже сделал небезопасный запрос к тому времени, когда он покажет пользователю это сообщение). Теперь этот запрос GET/POST с конфиденциальными данными сначала отправляется на эту неправильную обычную ссылку http://, и автоматическая перезапись говорит браузеру повторить попытку запроса через https://. Это выглядит хорошо, потому что, насколько это касается пользователя, все это произошло за долю секунды. Однако это не так: конфиденциальные данные были отправлены ясно.
Создание простой секции HTTP того, что должно быть только над HTTPS, не делает ничего полезного, фактически помогает вам понять, что неправильно. Поскольку пользователи никогда не должны заканчиваться там, если ссылки правильно реализованы, для них это не проблема.
Попробуйте добавить это перед другими правилами (но после RewriteBase):
RewriteCond %{HTTPS} off
RewriteRule ^cart/(.*)$ https://www.mydomain.com/cart/$1 [R,L]