Force HTTPS для конкретного URL

Question

Это должно быть быстрым один ... вот мой текущий файл .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/

Answer 1

Как только запрос был отправлен на адрес http://www.mydomain.com/cart/, если в запросе есть какие-либо конфиденциальные данные, слишком поздно. Заставьте его сломаться! По крайней мере, это даст вам указание, что с вашими ссылками что-то не так. Более подробно в предыдущих ответах:

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

[...] к тому времени, запрос достигает сервера, это слишком поздно. Если есть 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, не делает ничего полезного, фактически помогает вам понять, что не так ясно. Поскольку пользователи никогда не должны заканчиваться там, если ссылки правильно реализованы, для них это не проблема.

Answer 2

Попробуйте добавить этот перед другие правила (но после RewriteBase):

RewriteCond %{HTTPS} off 
RewriteRule ^cart/(.*)$ https://www.mydomain.com/cart/$1 [R,L]