Многократные перенаправления в рельсах при перенаправлении на HTTPS - PullRequest
Новая
       10

Многократные перенаправления в рельсах при перенаправлении на HTTPS

0 голосов
/ 13 сентября 2011

Ситуация следующая (я использую 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 из своего браузера (слишком много перенаправлений). Может кто-нибудь указать, что здесь происходит за капотом? Спасибо.

Ответы [ 3 ]

1 голос
/ 14 сентября 2011

Я бы обработал этот редирект через рельсы вместо apache.Меньшая вероятность ошибок и устраняет связь вашего приложения rails с определенным веб-сервером (в данном случае 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
0 голосов
/ 14 сентября 2011

Ну, ответ был более или менее неправильной конфигурации виртуальных хостов.Директивы NameVirtualHost распространялись буквально повсюду в отдельных файлах, каждый из которых настраивал свои собственные виртуальные хосты.С тех пор я объединил все директивы NameVirtualHost в один файл, который загружается перед загрузкой какого-либо одного виртуального хоста.

Один из виртуальных хостов фактически использовал хост с неверным именем.В частности, промежуточная среда и среда разработки / тестирования устанавливаются локально, но доступ к ним осуществляется по разным URL-адресам.Один был http://data.localhost/ настроен в / etc / hosts, а другой - http://data.domain.name/. Так что первый разрешается до 127.0.0.1, а другой - 192.168.xx Однако оба виртуальных хоста пытались разрешитьдо 127.0.0.1, так что очевидно, что это сломало вещи.Я просто указал правильные именованные хосты для каждой конфигурации хоста и снова включил правила перезаписи, и все было в порядке с перенаправлением с HTTP на HTTPS при доступе к странице входа в систему и наоборот для доступа к любой другой странице.

TL; DR у вас, вероятно, всегда должен быть один файл, содержащий все ваши директивы NameVirtualHost, и убедитесь, что он загружен перед всеми вашими виртуальными хостами.Это избавит вас от головной боли.Также активно подумайте, действительно ли ваш виртуальный хост, который вас портит, использует правильный хост.Затем убедитесь, что директива ServerName не вызывает конфликтов с другими виртуальными хостами, и у вас будет счастливое виртуальное семейство Apache!

0 голосов
/ 14 сентября 2011

Я бы посоветовал не использовать SSL-управление на уровне приложений, если у вас есть доступ к конфигурации веб-сервера, и каждая страница должна находиться за HTTPS-соединениями. Почему это так?

Пока вы работаете над простым приложением, нет причин иметь балансировщик нагрузки между приложением и внешним устройством. Но когда вам нужно управлять балансировкой нагрузки и иметь среду резервного копирования, Балансировщик нагрузки - это решение.

Поскольку SSL-рукопожатие и запрос на подпись занимают циклы ЦП, балансировщик нагрузки может общаться с каждым внутренним веб-сервером без SSL, но с внешним.

Если ваше приложение растет , думайте о частях среды как layer . Каждый из слоев несет ответственность. Сочетание ответственности может занять место, только если вы этого хотите.

...