Por que o IE não permite que os usuários façam login em um site, a menos que estejam no modo Privado?

4

Não tenho certeza se isso pertence ao SuperUser.com. Eu também considerei ServerFault.com e StackOverflow.com, mas, no final, acho que deveria pertencer aqui?

Hospedamos um site com o mesmo código que responde a vários nomes de domínio. No dia 28 de dezembro (sem nenhuma alteração implantada no site), uma porcentagem de usuários de repente não pôde fazer login, e a página de login em branco foi renderizada novamente mesmo quando as credenciais corretas foram inseridas. A questão ainda está em andamento.

Depois de controlar remotamente o PC de um usuário afetado, encontramos o seguinte:

  • O problema afeta o Internet Explorer 9.
  • O usuário pode fazer login na mesma máquina no Chrome.
  • O usuário pode efetuar login em uma sessão do navegador In Private usando o IE9.
  • O usuário pode fazer login se o site for adicionado à zona de segurança dos Sites confiáveis.
  • O usuário NÃO pode efetuar login de uma sessão do IE no modo de segurança (iniciado com iexplore -extoff ).
  • Apenas um nome de host ao qual o site responde evita login, a mesma conta de usuário no outro nome de host funciona bem (observe que esse é um código e banco de dados idênticos em execução no servidor), embora esse site não esteja na zona de sites confiáveis. / li>

Série de solicitações HTTP no caso de falha:

  1. OBTER a solicitação para a página protegida, retorna uma resposta 302 FOUND para a página de login.
  2. OBTER solicitação para acessar a página.
  3. POST para a página de login, contendo credenciais, retorna o redirecionamento para a página protegida.
  4. OBTER a solicitação para a página protegida ... por algum motivo, a autenticação falha e o navegador é redirecionado para a página de login, como na etapa 1.

Outras informações:

  • O sistema operacional é o Windows 7 Ultimate Edition.
  • O sistema AV é o AVG Internet Security 2012.

Eu posso pensar em muitas coisas que poderiam estar dando errado, mas em todos os casos, uma das descobertas acima é incompatível com a teoria.

Alguma idéia do que está causando o login falhar?

Atualização 06-jan-2012

O registro aprimorado mostrou que o cookie .ASPXAUTH está sendo definido na etapa 3. Sua data de expiração é 28 dias no futuro, seu caminho é / , o domínio é mysite.com e seu valor é criptografado forma o ticket, como esperado.

No entanto, o cookie não está sendo recebido pelo servidor web durante a etapa 4. Outros cookies estão sendo apresentados ao servidor durante a etapa 4, é apenas este que está faltando.

Eu vi que os cookies geralmente são configurados com um domínio que começa com um período, mas o meu não é. Deve ser .mysite.com em vez de mysite.com ? No entanto, se isso estivesse errado, presumivelmente afetaria todos os usuários?

    
por Richard Fawcett 04.01.2012 / 11:40

4 respostas

2

Minha análise na minha atualização sobre o cookie não sendo retornado para o servidor estava incorreta. Em algum momento antes da execução do meu código de log, o cookie estava sendo expurgado do lado do servidor da coleção de cookies.

Usando o Wireshark, determinei que, na verdade, duas cópias do cookie .ASPXAUTH estavam sendo enviadas para o servidor, uma inválida e outra válida. Tecnicamente, a ordem dos cookies é não-determinística, então acho que estava afetando as pessoas cujos navegadores estavam enviando um cookie inválido primeiro ... A ASP.NET simplesmente não considerou o segundo cookie válido.

Como mencionado acima, o cookie em questão era .ASPXAUTH , que é o nome padrão do cookie de autenticação do .NET. Acreditamos que existissem duas cópias do mesmo, como se ele tivesse sido enviado em um domínio diferente no passado (uma vez como www.mysite.com e em um momento diferente como .mysite.com ).

A solução mais fácil, que funcionou perfeitamente, foi alterar o nome do cookie de autenticação, definindo o seguinte em Web.config :

<authentication mode="Forms">
    <forms name="SOMEOTHERCOOKIENAME" />
</authentication>

Em seguida, certifique-se de que o novo cookie só será enviado com um único valor que corresponderá a uma solicitação específica!

    
por 10.01.2012 / 10:31
1

Any ideas what is causing login to fail?

Cookies.

  • O modo privado provavelmente tem um conjunto separado de cookies (caso contrário, dificilmente seria privado)
  • Navegadores diferentes têm cookies separados
  • Os cookies geralmente são específicos do nome de domínio do site.

Tudo isso é consistente com a descrição do seu problema.

Atualização:

  • Verifique suas configurações de cookies para a zona de segurança relevante (Internet, local, confiável, restrito).
    No IE8: Tools, Internet Options, Privacy, Sites
    Talvez mysite.com esteja bloqueado na zona relevante?

  • Verifique seus cookies reais
    No IE8: Tools, Internet Options, General, Browsing History, Settings, View Files
    Procure por cookie:username/mysite.com/

  • Verificar configurações de manipulação de cookies não padrão
    Eles podem bloquear cookies de "terceiros" (se isso se aplicar)
    O pode optar por ser solicitado a aceitar / rejeitar novos cookies.

Você diz "O usuário pode fazer o login se o site for adicionado à zona de segurança dos Sites Confiáveis". Isso implica que mysite.com pode ser bloqueado em uma das outras zonas que normalmente se aplicam a mysite.com .

    
por 04.01.2012 / 12:19
1

Eu tinha algo muito semelhante, o cookie de autenticação do ASP.NET não estava sendo definido no IE ou no Chrome, embora fosse estranho no Firefox (ainda não tenho explicação para o motivo).

O que acabou sendo o problema para mim foi que a hora do servidor estava incorreta, eram 30 minutos no passado. Então, às 9:50, quando eu entrei no site, o servidor definiu o tempo de expiração do cookie às 10:10, mas meu computador tinha o tempo de 10:20, então o cookie já tinha expirado. A atualização do tempo no servidor resolveu o problema para mim

    
por 12.04.2012 / 12:28
0

Nas Opções da Internet do Explorer, Geral, Histórico de Navegação, Configurações, Você pode tentar alterar a configuração "Verificar nova versão ..." de "Automaticamente" (3ª escolha) para "Toda visita ..." (1ª escolha) .

Eu tive um problema quase idêntico e essa solução funcionou. Nunca encontrei qual era o problema ...

Além disso (mas não acho que seja o seu caso), verifique a diferença de relógio entre o servidor e os clientes.

    
por 04.01.2012 / 13:19