重定向到HTTPS时在Rails中进行多次重定向

Question

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.

Answer 1

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

Answer 2

I'd suggest do not use SSL hanldling on Application layer if you have an access to webserver configuration and every page should be behind the HTTPS connections. Why is that?

While you are working on a simple application, no reasons to have load balancer between the application and outside. But when you should manage load balancining and have backup environment, the Load balancer is a solutuon.

Since SSL handshake and sign request takes CPU cycles, the Load Balancer can talk to each internal webserver without SSL, but the outside.

In case of your application is growing , think about parts of environment as layers . Each of layers has responsibility. Mix of responsibility can take a place only if you want you do.

Answer 3

Well, the answer was more or less a miss-configuration of the virtual hosts. There were NameVirtualHost directives spread out literally everywhere in separated files that each configured their own virtual hosts. I have since consolidated all of the NameVirtualHost directives into a single file that loads before any single virtual host is loaded.

One of the virtual hosts was actually using the wrong named host. Specifically, both the staging environment and development/testing environment are installed locally, but are accessed under differnet URLs obviously. One was http://data.localhost/ configured in /etc/hosts and the other was http://data.domain.name/ . So the former resolves to 127.0.0.1 and the other resolves to 192.168.xx However, both the virtual hosts were trying to resolve to 127.0.0.1, so obviously that was breaking things. I just specified the correct named hosts for each host configuration and re-enabled the rewrite rules and all was well with redirection from HTTP to HTTPS when accessing the login page, and vice versa for accessing every other page.

TL;DR you should probably always have a single file that has all of your NameVirtualHost directives, and ensure this is loaded before all of your virtual hosts. It will save you many, many a headache. Also actively think about if your virtual host that is screwing you up is actually using the correct host. Then, ensure that the ServerName directive is not causing conflict with other virtual hosts, and you will have a happy virtual Apache family!