Magento - Usuários incapazes de logar de redes corporativas com balanceadores de carga Bluecoat / F5

Question

Esperando que alguém tenha se deparado com esse problema antes com o Magento e clientes corporativos.

Temos dois clientes para o nosso site Magento que têm suas redes internas configuradas usando dispositivos de segurança bluecoat e balanceadores de carga F5. Alguns usuários dentro dessas redes não conseguem acessar o Magento - Magento eventualmente está enviando um redirecionamento 302 para /index.php/ quando os usuários tentam efetuar o login.

Por meio de nossos testes, o problema parece estar isolado dessa configuração - podemos fazer login nas contas em questão de qualquer lugar fora dessas redes sem problemas e se o cliente tentar acessar o site sem passar pelo balanceador de carga F5 , eles podem fazer login com sucesso.

Curiosamente, o problema só começou a ocorrer nos dois sites no dia seguinte à introdução de uma atualização do sistema que adicionou um novo site à instalação do Magento. A atualização do sistema não deve ter afetado qualquer funcionalidade de login padrão e, como dito, o problema não parece ser com os usuários em questão, mas com o local de onde os usuários estão acessando o site.

Inicialmente pensamos que o problema poderia ter algo a ver com as comunicações entre as redes do cliente e a rede em que o servidor estava hospedado, por isso tentamos mover o servidor para hosts diferentes, mas isso não ajudou.

Atualmente, estou aguardando mais informações dos clientes em dispositivos / modelos exatos usados na configuração da rede. Eu atualizarei este post se mais informações ficarem disponíveis.

A versão Magento é a edição corporativa do ver. 1.9.0.0

Alguém sabe de alguma configuração do Magento escondida que possa causar esse tipo de comportamento? Experiência com este tipo de configuração e idéias para coisas para olhar?

Toda ajuda e ideias para acompanhamento serão apreciadas, já que esta é uma questão de produção atual para um grande número de usuários. Responderei o mais rápido possível a qualquer solicitação de informações adicionais sobre o tópico, mas atualmente não posso divulgar nenhuma informação de identificação sobre o projeto em questão e / ou os clientes com problemas.

Agradecemos antecipadamente por qualquer assistência oferecida:)

Nota: Esta questão também foi publicada nos fóruns do Magento: link E também no estouro de pilha (movido aqui como um comentarista pensou que este site pode ser mais adequado): link

    

Answer 1

Parece que você isolou o problema no F5. Qual modelo do dispositivo F5 você está executando e quais módulos você está executando em cima dele? Por exemplo, o ASM é o Web App Firewall da F5 e, se estiver ativado, pode fazer com que os aplicativos parem de funcionar.

Além disso, o F5 LTM tem a capacidade de implementar algo chamado iRules. Basicamente, é uma linguagem de script baseada em TCL para implementar lógica no fluxo de tráfego. Talvez exista uma lógica implementada em uma iRule (ou configuração geral do servidor virtual) que está causando falhas nas tentativas de login dos usuários.

Uma coisa que você pode tentar é criar um novo servidor virtual de encaminhamento ou desempenho para separar ainda mais possíveis problemas com um elemento de configuração existente com o servidor virtual existente.

    

Answer 2

Parece que você precisa configurar a persistência . O que pode acontecer nessa situação é que você fará o login no servidor de backend A) e, em seguida, nas solicitações futuras, será conectado ao servidor B). Você nunca logou no servidor B) e você é redirecionado de volta para a página de login. Isso atrapalha os dados de login no navegador local para o servidor A) quando você faz o login no servidor B) e então parece que você nunca está logado porque você precisa logar em A) novamente quando você tem carga balanceada lá atrás. / p>

Caso contrário, você provavelmente está usando um método de autenticação mais exótico (certificados SSL de clientes, Kerberos, NTLM, etc) e precisa fornecer mais detalhes.