我想在用户访问网站的“帐户”部分时将其重定向到SSL安全服务器,该部分将包含用户个人资料,设置等表单。但是,我不希望用户能够访问SSL服务器上的其余站点。由于我对模板的编码方式,我将路径设置为<a href="/about">
作为示例。如果它们位于“帐户”部分并单击“关于”部分的链接,则它们仍将位于安全的https:连接上。显然,我可以硬编码链接到http://服务器的链接,但我正在寻找替代方案。
到目前为止,我在.htaccess中有以下内容并且它正在运行,但我想知道这是否需要更多的资源密集型?将链接硬编码到任何其他“非帐户”部分是否更好,或者通过.htaccess进行此操作是一个很好的方法来实现它?
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond $1 ^(account) [NC]
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTPS} on
RewriteCond $1 ^(about|terms|products) [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
另外,如果我想阻止通过https://访问主页,我该如何将其添加到我的.htaccess文件中?
答案 0 :(得分:1)
我实际建议避免使用重写规则。
将http
请求转换为https
请求的重写规则的问题在于它们实际上是重定向。这意味着,对于要转换为http
请求的每个https
请求,浏览器首先会发出完整的http
请求(包括内容,Cookie,除了安全的请求) ,从服务器获取重定向代码,然后再次向https
重写的URL发送请求。
虽然这很方便,但如果您依赖此而不是确保您网站上的https
部分中的链接确实使用https
,则会很难检测到当这些链接错误地重定向到http
变体时。
典型的后果是:
http
嵌入的内容稍后自动且透明地转换为https
,这是一件坏事;和相反,我建议您不要使用自动重写/重定向,并确保仅通过HTTPS提供的部分在普通HTTP变体上根本不可用(即http://yourhost/account
应该返回404s):这将至少迫使您注意到错误链接并帮助您找到可能存在安全问题的位置。最终,虽然它们共享相同的主机名,但http
站点和https
站点可以有两个不同的URL空间:在这种情况下,这不是一件坏事。
我想看到从http
到https
重写的唯一情况非常有用,就是当您想要确保重定向用户的网站入口点时。
从https
到http
的重写当然不会出现此问题。