Цикл перенаправления в PHP за балансировщиком нагрузки с SSL - PullRequest
Новая
       35

Цикл перенаправления в PHP за балансировщиком нагрузки с SSL

3 голосов
/ 22 марта 2012

У меня возникает ситуация, когда я зацикливаюсь на бесконечном цикле перенаправления, когда пытаюсь переключиться с зашифрованных страниц SSL обратно на незашифрованные (https -> http). Наша текущая конфигурация установлена ​​за балансировщиком нагрузки, который создает заголовок: HTTP_X_FORWARDED_PROTO

Когда установлено SSL, возвращается «https», а всегда возвращается «http»

Следующий код, который я использовал на сайте до переноса сертификата SSL на балансировщик нагрузки вместо веб-узла, на котором работает сайт. (HTTP_X_FORWARDED_PROTO) были добавлены для соответствующего обновления скрипта. 

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])){
    $redirect = '';
    if (!isset($sslPage)){
        $sslPage = false;
    }
    switch($_SERVER['HTTP_X_FORWARDED_PROTO']){
        case 'http' :
            if ($sslPage)
                $redirect = 'location: https://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
            break;  

        case 'https' :
            if (!$sslPage)
                //$redirect = 'location: http://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
            break;
    }
    if (!empty($redirect)){
        header ($redirect); 
    }
}

На каждой странице, для которой требуется ssl, предварительно загружена переменная $ sslPage = true;

Так что перенаправление с http на https прекрасно работает .. без проблем. Но если я попытаюсь вернуться назад, это не сработает. Я застреваю в бесконечной петле. Я начинаю думать, что это из-за Apache. Поскольку веб-узел больше не завершает SSL, весь трафик к нему проходит через порт 80. Когда php выполняет перенаправление через header (), я полагаю, что происходит, когда сервер собирает запрос, поскольку он локальный, и пытается его проанализировать. Поскольку HTTP_X_FORWARDED_PROTO никогда не обновляется, поскольку он больше не попадал на балансировщик нагрузки, перенаправление никогда не может быть успешным.

У меня вопрос: имеет ли это смысл или я ошибся, подумав об этом? Будет ли этот вызов всегда перенаправляться обратно на балансировщик нагрузки? Если он остается внутренним для этого веб-узла, как я могу заставить его вернуться к Балансировщику нагрузки, чтобы он мог записывать новые заголовки для страницы, которую он пытается получить?

Это оказалось разочаровывающим ....

Спасибо за вашу помощь заранее.

Ответы [ 2 ]

6 голосов
/ 22 марта 2012

Вы можете просто позволить Apache думать, что SSL включен, установив переменную среды (в логике PHP $_SERVER['HTTPS']) 

SetEnvIf X-Forwarded-Proto https HTTPS=On

Это должно позволить вашему унаследованному коду работать без изменений.

2 голосов
/ 17 декабря 2012

Мы только что столкнулись с чем-то похожим и обнаружили, что это был наш балансировщик нагрузки Zeus, мешающий заголовку ответа.Мы обнаружили, что все отправленные обратно заголовки 301/302 были изменены балансировщиком нагрузки, если первоначальный запрос был сделан по https, а возврат был на незащищенную страницу.

Например, если клиент запросил https://site.com и мы перенаправили на http://site.com с 302, результат обратно на стороне клиента будет иметь " Location: https://site.com", потому что балансировщик нагрузки переключил его обратно (вместоожидаемого " Местоположение: http://site.com")

Эта проблема была решена путем отключения этой функции в балансировщике нагрузки.

Надеюсь, что это кому-то поможет - это неприятная проблема, чтобы попробоватьна дно!

...