重定向到 HTTPS 时，rails 中的多个重定向

发布于 2024-12-04 12:48:46 字数 417 浏览 3 评论 0原文

情况如下（我使用的是Rails 3.1）。

我有以下路线：

match 'login', :to => 'sessions#new'

非常标准。我的 Apache 虚拟主机文件中也有此重定向规则：

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (/login$) https://%{HTTP_HOST}%{REQUEST_URI}

当我导航到 https://hostname.dom/login 我从浏览器收到 301 状态代码（重定向过多）。有人能指出这里的幕后发生了什么吗？谢谢。

原文

The situation is as follows (I am using Rails 3.1).

I have the following route:

match 'login', :to => 'sessions#new'

Pretty standard. I also have this redirect rule in my Apache virtual hosts file:

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (/login$) https://%{HTTP_HOST}%{REQUEST_URI}

When I navigate to https://hostname.dom/login I get a 301 status code from my browser (too many redirects). Can someone point out what's going on behind the hood here? Thanks.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

对你而言 2024-12-11 12:48:46

我会通过 Rails 而不是 apache 来处理这个重定向。出错的可能性较小，并且消除了 Rails 应用程序与某个 Web 服务器（本例中为 apache）的耦合。
对于 Rails 3.0.X 和以前的使用
SSL_Requirement 对于 3.1.X 及更高版本，它是在 'force_ssl' 方法。

ssl_requirement 示例：

class ApplicationController < ActiveRecord::Base
  include SslRequirement
end

class SessionController < ApplicationController
  ssl_required :new, :create

  def new
    # Non-SSL access will be redirected to SSL
  end
end

force_ssl 示例：

class SessionController < ApplicationController
  force_ssl :only =>  :new, :create

  def new
    # Non-SSL access will be redirected to SSL
  end
end

I would handle this redirect through rails instead of apache. Less chance of errors and Removes coupling of your rails app to a certain web server(apache in this case).
For Rails 3.0.X and previous use
SSL_Requirement and for 3.1.X and later use it's baked in 'force_ssl' method.

ssl_requirement example:

class ApplicationController < ActiveRecord::Base
  include SslRequirement
end

class SessionController < ApplicationController
  ssl_required :new, :create

  def new
    # Non-SSL access will be redirected to SSL
  end
end

force_ssl example:

class SessionController < ApplicationController
  force_ssl :only =>  :new, :create

  def new
    # Non-SSL access will be redirected to SSL
  end
end

回复收藏 0 原文

弄潮 2024-12-11 12:48:46

如果您有权访问网络服务器配置并且每个页面都应该位于 HTTPS 连接后面，我建议不要在应用程序层上使用 SSL 处理。这是为什么？

当您正在开发一个简单的应用程序时，没有理由在应用程序和外部之间使用负载平衡器。但是，当您需要管理负载平衡并拥有备份环境时，负载平衡器是一个解决方案。

由于 SSL 握手和签名请求需要 CPU 周期，因此负载均衡器可以在没有 SSL 的情况下与每个内部 Web 服务器通信，但可以与外部通信。

如果您的应用程序正在增长，请将环境的各个部分视为层。每一层都有责任。只有当你愿意的时候，混合责任才能发生。

回复收藏 0 原文

一个人的夜不怕黑 2024-12-11 12:48:46

好吧，答案或多或少是虚拟主机的配置错误。 NameVirtualHost 指令分布在各个单独的文件中，每个文件都配置了自己的虚拟主机。此后，我将所有 NameVirtualHost 指令合并到一个文件中，该文件在加载任何单个虚拟主机之前加载。

其中一台虚拟主机实际上使用了错误的命名主机。具体来说，登台环境和开发/测试环境都安装在本地，但显然是在不同的 URL 下访问的。一个是在 /etc/hosts 中配置的 http://data.localhost/ ，另一个是 http://data.domain.name/。因此，前者解析为 127.0.0.1，另一个解析为 192.168.xx 但是，两个虚拟主机都试图解析为 127.0.0.1，所以显然这会破坏事情。我只是为每个主机配置指定了正确的命名主机，并重新启用了重写规则，并且在访问登录页面时从 HTTP 重定向到 HTTPS 一切顺利，反之亦然，访问每个其他页面时也是如此。

TL;DR 您可能应该始终拥有一个包含所有 NameVirtualHost 指令的文件，并确保在所有虚拟主机之前加载该文件。它会为你省去很多很多的麻烦。还要积极考虑让您陷入困境的虚拟主机是否实际上使用了正确的主机。然后，确保 ServerName 指令不会与其他虚拟主机发生冲突，您将拥有一个幸福的虚拟 Apache 系列！

回复收藏 0 原文

~没有更多了~