Аутентификация Symfony - не может пройти мимо страницы входа в систему

Question

Я установил проверку подлинности Symfony на своем локальном dev-сервере, она отлично работает как в средах prod, так и в dev, сегодня я зарегистрировал домен для тестирования и отправил свой код на сервер AWS EC2, я могу войти в систему На странице нет проблем, но как только я пытаюсь войти, я сразу же возвращаюсь на страницу входа без ошибок. Кажется, что, когда он отправляет в login_check, он перенаправляет прямо обратно в / login Я попытался очистить и подогреть кэш-память с отладкой и без нее, что, похоже, не решает проблему. В моем файле prod.log нет ошибок.

Есть предложения по устранению неполадок?

Спасибо.

Edit: Это отображается в журнале разработчиков:

[2012-03-26 22:52:59] security.INFO: Authentication request failed: Your session has    timed-out, or you have disabled cookies. [] []
[2012-03-26 22:52:59] security.DEBUG: Redirecting to /login [] []

Редактировать Каждый раз, когда я обновляю страницу, я получаю два новых файла cookie: sub.domain.com и .domain.com. Если я смотрю на сервере в / tmp / dir, где сохраняются сессии, при каждом обновлении страницы создается 6 новых сессий. у двух, показанных в chrome dev tools, нет данных внутри. Эта проблема не существует на моем локальном сервере разработки. Любые предложения о том, что может быть причиной этого, приветствуются !!!

Редактировать - Разрешение

Я удалил куки из Chrome, и они неожиданно начали работать. Не уверен, в чем корень проблемы, но теперь все работает нормально.

Answer 1

При запуске Symfony 2.3 в конфигурации secure.yml есть настройка require_previous_session, установите значение false:

    secured_area:
        ...
        form_login:
            ...
            require_previous_session: false

Answer 2

Совет: проверьте config_prod.yml на наличие незначительных различий в конфигурации.

Я столкнулся с той же проблемой при тестировании среды prod на моей локальной машине;в то время как я мог проходить аутентификацию на dev, я не мог проходить аутентификацию на prod, который выдал ошибку, указанную в OP:

security.INFO: Authentication request failed: Your session has timed-out, or you have disabled cookies. [] []

отключенные куки бит заставили меня задуматься.

Далее я проверил вкладку сети в своем браузере и достиг пика при моем запросе / ответе для страницы.Я заметил, что cookie-файл сеанса был предоставлен в ответе сервера, но не был отправлен браузером в запросе.

Тогда у меня был момент ага:

Я использовал безопасные куки-файлы при незашифрованном соединении

На нашем производственном сервере весь незашифрованный трафик перенаправляется в соединение TLS, поэтомуимеет смысл использовать безопасные куки в среде prod; в config_prod.yml :

framework:
    session:
        cookie_secure: true

В результате к cookie-файлу сеанса добавляется secure:

Set-Cookie:PHPSESSID=66117caf467ef2bf8efee373b52449ba; path=/; secure; HttpOnly

в соответствии с браузерами / пользователями-агенты:

не будут отправлять cookie с установленным флагом безопасности для незашифрованного HTTP-запроса.

Недостатком является то, что собственная обработка php не знает и не заботитсяо безопасном флаге (он добавлен Symfony), поэтому cookie-файл сеанса все еще может быть отправлен через незашифрованное соединение, и браузер (или, по крайней мере, Chrome 35) будет - в замешательстве - на самом деле использовать secure cookie получено через незащищенное / незашифрованное соединение.Я предполагаю, что это не так озадачивает, ответственность за аннулирование сеансов несут серверы, а не браузеры.

Решение

Я установил https на моем локальном компьютере.машина, чтобы я мог протестировать окружение prod, не задумываясь о конфигурации.Применение только https-соединений только для производства позволило моей команде упростить ситуацию, но немного меня расстроило.

Уберите: чем выше соотношение между местным и производством, тем лучше!

Answer 3

Ну, это работает на вашем локальном сервере, поэтому у вас определенно включены куки. :)

Как я уже сказал в комментарии, вы должны проверить, правильно ли настроен сеанс в php.ini. Это включает, среди прочего:

• "session.save_path",
• "session.auto_start".

Также отметьте в Firebug, что вы получили действительный файл cookie PHPSESSID (или что-то подобное, в зависимости от вас php.ini). Еще одна вещь, которую вы можете проверить, это config.yml файл для такой детали:

session:
        default_locale: %locale%
        auto_start:     true
        lifetime:       86400

Это все дикие догадки, но я подозреваю, что "session.save_path" не доступен для записи в вашей файловой системе ...