Надеюсь, что кто-то уже сталкивался с этой проблемой раньше с Magento и корпоративными клиентами.
У нас есть два клиента для нашего сайта Magento, у которых внутренние сети настроены с использованием устройств безопасности bluecoat и балансировщиков нагрузки F5. Некоторые пользователи в этих сетях не могут войти в Magento - Magento в конечном итоге отправляет 302 редирект на /index.php/, когда пользователи пытаются войти в систему.
Благодаря нашему тестированию проблема, похоже, изолирована от этой настройки - мы можем без проблем входить в указанные учетные записи из любого места за пределами этих сетей, и если клиент пытается получить доступ к сайту, не проходя через балансировщик нагрузки F5, они смог успешно войти в систему.
Как ни странно, проблема начала возникать для двух сайтов только на следующий день после того, как мы представили обновление системы, которое добавило новый сайт в установку Magento. Обновление системы не должно было повлиять на какие-либо стандартные функции входа в систему, и, как уже говорилось, проблема, по всей видимости, связана не с указанными пользователями, а с тем, откуда пользователи получают доступ к сайту.
Первоначально мы думали, что проблема может иметь какое-то отношение к связи между сетями клиента и сетью, в которой размещен сервер, поэтому мы пытались переместить сервер на другие хосты, но это не помогло.
В настоящее время я жду от клиентов дополнительной информации о конкретных устройствах / моделях, используемых при настройке их сети. Я обновлю этот пост, если появится дополнительная информация.
Версия Magento - это корпоративная версия вер. 1.9.0.0
Кто-нибудь знает о каких-либо скрытых настройках Magento, которые могут вызвать такое поведение? Опыт работы с подобными установками и идеи на что посмотреть?
Мы будем благодарны за любую помощь и идеи для дальнейших действий - поскольку это текущая производственная проблема для большого числа пользователей. Я отвечу как можно скорее на любые запросы о дополнительной информации по теме, но в настоящее время я не могу раскрыть какую-либо идентифицирующую информацию о рассматриваемом проекте и / или клиентах, у которых возникли проблемы.
Заранее благодарим за любую предложенную помощь :)
Примечание. Этот вопрос также был размещен на форумах Magento: http://www.magentocommerce.com/boards/viewthread/277917/ А также о переполнении стека (перемещено сюда, поскольку комментатор подумал, что этот сайт может быть лучше подходит): https://stackoverflow.com/questions/10133978/magento-users-unable-to-login-from-corporate-networks-with-bluecoat-f5-load
Похоже, вы изолировали проблему от F5. На какой модели устройства F5 вы работаете и какие модули устанавливаете поверх него? Например, ASM - это брандмауэр веб-приложений F5, и если он включен, это может привести к прекращению работы приложений.
Кроме того, в F5 LTM есть возможность реализовать так называемые iRules. По сути, это язык сценариев на основе TCL для реализации логики в потоке трафика. Возможно, в iRule (или общей конфигурации виртуального сервера) реализована логика, которая приводит к сбою попыток входа пользователей в систему.
Одна вещь, которую вы можете попробовать, - это создать новый виртуальный сервер пересылки или производительности для дальнейшего разделения любых потенциальных проблем с существующим элементом конфигурации с существующим виртуальным сервером.
Похоже, вам может потребоваться настроить упорство. Что может случиться в этой ситуации, так это то, что вы войдете на внутренний сервер A), а затем при будущих запросах окажетесь подключенными к серверу B). Вы никогда не входили на сервер B), и вас перенаправляют обратно на страницу входа. Это сбивает данные входа в локальный браузер для сервера A), когда вы входите на сервер B), и тогда кажется, что вы никогда не входили в систему, потому что вам нужно снова войти в систему A), когда вы снова получите балансировку нагрузки.
В противном случае вы, вероятно, используете более экзотический метод аутентификации (клиентские SSL-сертификаты, Kerberos, NTLM и т. Д.), И вам нужно предоставить более подробную информацию.