Por que tornar a página de login em um aplicativo de página única uma página separada?

28

Gostaria de saber por que parece ser popular ter a página de login de um SPA como uma página separada que não seja a página do SPA (como carregada e enviada dados através de solicitações de ajax)?

Só consigo pensar em segurança, mas não consigo pensar em um motivo específico de segurança. Quero dizer, a única coisa que vem à mente é que, se sua página de login faz parte do SPA, ela envia o nome de usuário / senha através do ajax, o que pode ser visto por ferramentas como firebug ou web inspector, mesmo que você a envie normalmente Após a solicitação do POST, existem outras ferramentas que podem capturar facilmente esses dados (como violinista, httpscoop, etc ...).

Há algo que estou perdendo?

javascript architecture

— ryanzec
fonte

2

Eu não acho que exista ou precise haver uma razão nesse caso. Eu argumentaria, por que não?

— Steven Evers

1

Meu argumento contra isso seria que ter a página de login como uma página html separada, enquanto o restante do aplicativo é uma arquitetura SPA, parece estranho sem nenhum benefício real (embora o argumento que msanford tenha feito tenha mérito).

— Ryanzec 25/10/12

@ryanzec Obrigado. Adicionei um exemplo na tentativa de ilustrar que há um benefício real. Primeiro, a economia de adiar o carregamento de ativos em outros lugares não é desprezível, especialmente no caso de falha no login (ou suspensão da conta, etc.). Segundo, é muito mais rápido implementar do que um sistema de módulo assíncrono baseado em dependências mais sofisticado, e o ciclo de vida do desenvolvimento é uma consideração importante (consulte o mantra do escritório da Opbeat * (contém vulgaridade)).

— msanford

"mesmo que você o envie como uma solicitação POST normal, existem outras ferramentas que podem capturar facilmente esses dados". Certamente seu formulário de login está protegido por HTTPS ?

— ajlane

@ajlane sim, meu login (e, na verdade, o aplicativo inteiro) vai ser correr atrás HTTPS

— ryanzec

18

Presumivelmente, é para economizar o carregamento de vários ativos do lado do cliente (como estruturas JavaScript pesadas, imagens etc. ) exigidos apenas pelo aplicativo.

Existem meios mais sofisticados de atingir uma meta de desempenho semelhante (consulte " Malte Ubl e John Hjelmstad: uma abordagem nova e eficiente para o carregamento de JavaScript - JSConf EU 2012 "), mas isso é muito rápido de implementar e pode ser igualmente eficiente, especialmente se seu aplicativo da web usa quase todos os seus recursos de qualquer maneira.

Você pode ver isso em estado selvagem em um site como o http://infogr.am beta:

http://infogr.am/login/ carrega jquery , raphael , js personalizado e 3 arquivos css.
http://infogr.am/beta/ (a página principal do SPI do aplicativo) carrega 10 estruturas javascript, 5 arquivos css externos e cerca de 60 imagens.

— msanford
fonte

Atualização: Em 2016, com o front-end angular2 e o back-end do JBoss, ainda fazemos isso pelo mesmo motivo.

— msanford

18

Penso que existem argumentos razoáveis a favor ou contra, e eu diria que a tecnologia também desempenha um papel na decisão.

Alguém poderia argumentar que ter uma "página" de login separada permite o uso de "Segurança de Diretório". Geralmente, qualquer pessoa pode ver a "página" de login, mas apenas usuários autenticados podem visualizar a "página" do aplicativo e seu "diretório". As rotas também podem ser bloqueadas, onde / Account / é diferente de / App / e cada uma possui seu próprio "perfil" de segurança.

Além disso, se você estiver usando uma abordagem de SPA e misturando autenticação com a experiência do aplicativo, a lógica pode ser complicada. Em vez de assumir que o usuário está "logado porque está aqui", você deve verificar constantemente o status de autenticação e perguntar "este usuário deve estar aqui".

Além disso, a página de login geralmente está no site voltado para o consumidor. Você acessa www.yourapp.com e possui informações sobre informações, contato, suporte, etc. e uma página de "login". autenticação, você pode redirecionar para uma série de destinos.

O motivo de eu manter uma página de login separada e o motivo pelo qual realmente tenho um aplicativo totalmente diferente para o meu site "voltado para o consumidor" é porque posso expor muito pouco aos não autenticados. Por acaso algum idiota começa a bater na minha página de login, eu não quero que isso afete o lado do aplicativo, mesmo que o login esteja apenas fazendo uma simples pesquisa de autenticação .. isso meio que me ajuda a impedir que o bozo afete meu experiência do usuário .. Na pior das hipóteses, meu site de consumidor fica inoperante e ninguém pode fazer login, mas pelo menos os usuários conectados não sabem e sua experiência não começa a desacelerar .. Não estou dizendo que essa é a opção à prova de balas .. mas pelo menos isolei o risco na área não autenticada ..

— hanzolo
fonte

1

A segurança geralmente é um grande motivo.

— 23612 JustinC

1

@ JustinC: explique-me em uma página separada para o login mais seguro?

— Ryanzec # 25/12

Não necessariamente por meio de atributos do sistema de arquivos (mas pode ser isso que a situação exige), mas pelo contêiner / servlet de aplicativo da web / tempo de execução / software por meio da aplicação de autenticação seletivaa / métodos de autorização aplicados em um recurso específico ou em um grupo de recursos como um todo (em termos práticos, um diretório): para a página de login e recursos estáticos específicos (imagens, folhas de estilo, páginas de erro), o acesso anônimo é geralmente suficiente; para outras páginas, pode ser necessária uma autenticação / autorização mais específica.

— 23412 JustinC

2

A autenticação fora do aplicativo isola a autenticação de ser uma preocupação do aplicativo. A segurança real dependerá da aplicação e tecnologia

— hanzolo

atualização 2017: IdentityServer

— hanzolo

10

Uma razão para fazer isso é porque você pode usar sessões normais baseadas em cookies. O usuário efetua login, a resposta envia o cookie juntamente com a página principal inicial ... e todas as chamadas ajax subsequentes enviam o cookie de volta ao servidor.

— GrandmasterB
fonte

6

Vejo alguns motivos para fazer isso:

Eu posso usar regras normais de controle de acesso baseado em caminho no web.xml.
Nunca posso ter certeza de que protegi todo o meu aplicativo Ajax corretamente e preciso fazer testes extensivos para ter confiança.
Posso delegar autenticação a uma estrutura (como Spring Security), a um aplicativo de terceiros ou a uma solução SSO (como CAS ou JOSSO).
Posso permitir que o navegador armazene em cache o nome de usuário e (opcionalmente) as senhas para o usuário.

— n0rm1e
fonte