Prefácio
Como o Angular é um aplicativo de uma página, a maioria dos recursos será carregada no navegador desde o início, portanto, você precisa prestar mais atenção ao momento da verificação e garantir que apenas os usuários que passaram a verificação possam ver a interface correspondente.
A autenticação neste artigo refere -se a como determinar se o usuário efetuou login e garantir que as necessidades de verificação do servidor possam ser atendidas em todas as comunicações com o servidor. Observe que ele não inclui o julgamento sobre se existe uma autoridade específica.
Para login, é principalmente aceitar o nome de usuário e a entrada de senha do usuário , enviá -lo ao servidor para verificação , processar a resposta de verificação e criar dados de autenticação no lado do navegador .
Duas maneiras de implementar a autenticação de identidade
Atualmente, existem duas categorias principais de métodos para implementar a autenticação de identidade:
Biscoitos
As páginas da web do navegador tradicional usam cookies para verificar a identidade. De fato, na camada de aplicação do navegador, basicamente não há necessidade de se preocupar com a verificação da identidade. As configurações dos cookies são concluídas pelo servidor. Ao enviar a solicitação, o navegador anexa automaticamente as informações de cookies correspondentes. Portanto, no código JavaScript, não há necessidade de escrever um código especial para isso. Mas toda vez que solicitar, trarei todos os dados de cookies.
Com a aplicação do CDN e o aumento gradual de dispositivos móveis, os cookies são cada vez mais incapazes de atender às necessidades complexas de autenticação de vários domínios.
Chave
De fato, a autenticação baseada em chaves não surgiu recentemente, já existe, ainda mais que a história dos cookies. Quando o navegador solicita o servidor, ele anexa a chave à solicitação de uma maneira específica, como nos cabeçalhos da solicitação. Para fazer isso, o código especial do cliente deve ser escrito para gerenciamento.
O padrão da Web Key （JSON Web Token） é uma autenticação típica usando uma chave.
Nos aplicativos da Web, se você estiver construindo APIs, deve priorizar o uso do método chave.
Login do processo
O login é o primeiro passo na verificação de identidade. Somente pelo login, os dados de verificação de identidade correspondentes podem ser organizados.
Precisa usar uma página de login separada?
Existem duas maneiras de lidar com as páginas de login:
Uma página de login separada irá para o aplicativo de uma página após a conclusão do login. Isso permite que o controle de acesso dos recursos do aplicativo de uma página para impedir que os usuários não login acessem e é adequado para cenários de aplicação de ferramentas de segundo plano ou gerenciamento. Mas na verdade reduz a experiência do usuário de aplicativos de uma página única
Execute o login em um aplicativo de página única , que está mais alinhada com o conceito de design de um aplicativo de página única e é mais adequado para cenários de produtos populares, porque as pessoas maliciosas sempre podem obter o código front-end do seu aplicativo de página única.
Uma página de login separada
De um modo geral, o objetivo de usar uma página de login separada é proteger as páginas que são saltadas após o login de serem acessadas por usuários anônimos. Portanto, na página de login, um formulário é construído e o método tradicional de envio de elogio (não-AJAX) é usado diretamente. Depois que o back-end valida o nome de usuário e a senha com sucesso, o HTML da página de aplicativo de um lado após a saída de login.
Nesse caso, você pode colocar diretamente as informações de autenticação na saída HTML, por exemplo, você pode usar o Jade para construir uma página como esta:
<!-Dashboard.jade-> Doctype htmlhtmlHtml link da cabeça (rel = "Stylesheet", href = "/Assets/App.e1c2c6ea9350869264da10DE799DCED1.CSS Script corporal. window.token =! {json.stringify (token)}; Div.MD-Padding (Ui-View) Script (src = "/Assets/App.84b1e53df1b4b23171da.js")Após o sucesso do nome de usuário e da senha, o back -end pode usar o seguinte método para renderizar e produzir html:
return res.render ('painel', {token: token});Depois que o aplicativo angular é iniciado, ele pode se comunicar com a autenticação. Também garante que apenas os usuários que fizeram login com sucesso possam entrar nesta página.
Organizações que fazem login em um aplicativo de uma única página
Para aplicações angulares de várias vistas, o roteamento é geralmente usado. Na página, geralmente há um menu fixo da barra lateral ou um menu de navegação superior, e a área de texto é controlada pelo módulo de roteamento.
O código de amostra a seguir usa material angular para organizar a página e o módulo de roteamento usa o ROUTER da interface do usuário. Quando o aplicativo é aberto, há uma animação de carregamento especial. Após a conclusão do carregamento, a página exibida é usada pelo controlador AppController . Para usuários que não estão conectados, um formulário de login será exibido. Após a conclusão do login, a página é dividida em três partes: uma é a navegação de farinha de pão superior , a segunda é o menu da barra lateral e a outra é a parte principal do controle da rota .
O código é o seguinte:
<corpo ng-app = "App" layout = "ROW"> <div id = "carregamento"> <!-Página carregando prompt-> </div> <div Layout flex = "linha" ng-cloak ng-controller = "AppController" ng-init = "load ()"> <div ng-if = "! iserauth",, ngin = "load ()"> <d) <!-Loginform-> </div> <div ng-if = "isUserauth" flex layout = "linha"> <md-sidenav flex = "15" md-is-locked -pen = "true"> <!-menu da barra lateral-"MDURO"> </md-sidenav> <md-contet Flex Layout = "Coluna" "Role =" Role </midenav> <Md-Contet Flex) </md----
Para carregar animações, elas estão fora AppController e podem ser ocultas no código AppController . Isso alcança o objetivo de carregar desaparecer depois que todo o CSS/JavaScript é carregado.
Existe uma variável no AppController isUserAuth É false quando inicializado. Quando as informações da sessão armazenadas localmente são válidas ou após a conclusão do login, esse valor será definido como ture . Devido ao controle do ng-if , o objetivo de ocultar o formulário de login e exibir o conteúdo do aplicativo pode ser alcançado. Deve-se notar que apenas usando ng-if em vez de ng-show/ng-hide aqui, o primeiro realmente excluirá e adicionará elementos DOM, enquanto o último modificará apenas os atributos CSS de um elemento DOM. Isso é muito importante. Somente dessa maneira podemos garantir que, após o login, o conteúdo no aplicativo de uma página seja carregado para impedir que o código do controlador na rota atual seja executado diretamente antes do login.
Por que os clientes também criptografam senhas
Um processo de login ideal com base no nome de usuário e senha é o seguinte:
1. O lado do navegador obtém a senha inserida pelo usuário, usa um algoritmo de hash, como o MD5, para gerar uma nova senha de comprimento fixo, como md5(username + md5(md5(password))) , e depois envia o valor do hash e o nome de usuário da senha para o back -end para o retorno
2. O back -end obtém o sal correspondente com base no nome do usuário, usa o nome do usuário e o valor de hash de senha, calcula um CifferText e pesquisa no banco de dados com base no nome do usuário e na senha
3. Se a consulta for bem -sucedida, gerar a chave, devolvê -la ao navegador e execute a Etapa 4
4. O back -end gera novo sal e gera um novo texto cifrado com base no novo sal e no valor do hash de senha enviado pelo navegador. Atualize sal e texto cifrado no banco de dados
Talvez 80% das pessoas não conseguem entender por que um login é tão complicado. Isso pode exigir um artigo especial para explicar claramente. Aqui vou explicar primeiro por que o navegador hash a senha e os motivos são os seguintes:
1. Proteja a senha do usuário da fonte para garantir que somente com os principais registros você pode obter a senha original do usuário
2. Mesmo que a rede seja desdém e HTTPS não seja usada, a senha roubada é somente após a hash, o que pode afetar os dados do usuário neste servidor, e não afeta outros sites que usam a mesma senha.
3. Mesmo o proprietário do servidor não pode obter a senha original do usuário.
Essa abordagem faz o maior risco para os usuários e os dados no aplicativo atual são roubados. O intervalo de perdas não será expandido e nunca haverá problemas com o CSDN ou outros fluxos.
Login Notificação bem -sucedida
Para alguns aplicativos, nem todas as páginas exigem que os usuários efetuem login. Eles podem precisar fazer login apenas ao executar determinadas operações. Nesse caso, após o login, todo o aplicativo deve ser notificado. Isso permite que você use a função de transmissão.
O código simples é o seguinte:
Angular .Module ('App') .Controller ('Logincontroller', ['$ Rootscope', Logincontroller]); função Logincontroller ($ RootScope) {// Função chamada depois); }}Em outros controladores, você pode ouvir esta transmissão e executar as operações que precisam ser executadas após o sucesso do login, como obter uma lista ou detalhes:
$ scope. $ on ('user.login.success', function (handle, dados) {// processing});Informações de autenticação de identidade
Após o login com sucesso, o servidor retorna a chave e as solicitações de API subsequentes precisam trazer a chave, e a resposta retornada pela solicitação também precisa ser verificada se é um erro sobre a invalidez das informações de identidade. Esta série de trabalho é bastante pesada e deve ser concluída automaticamente.
salvar
Existem aproximadamente as seguintes maneiras de salvar a chave:
1.COOKIES: Como mencionado anteriormente, isso não é recomendado. Ao mesmo tempo, também tem um limite máximo de 4K
2.SessionStorage: A página da guia é válida. Uma vez fechado ou uma nova página de guia é aberta, a SessionStorage não pode ser compartilhada.
3.LocalStorage: um método de armazenamento ideal. A menos que os dados do navegador sejam limpos, os dados armazenados no LocalStorage sempre existirão.
4. Serviço angular de singleton: se armazenado no aplicativo, os dados serão perdidos após a atualização e, é claro, não podem ser compartilhados entre as páginas da guia.
Uma abordagem melhor é que as informações de autenticação são armazenadas no LocalStorage, mas são inicializadas no serviço Singleton da Angular quando o aplicativo é iniciado.
Adicione informações de autenticação ao pedido
O objetivo das informações de autenticação de identidade é indicar identidade ao servidor e obter dados. Portanto, informações adicionais de autenticação são necessárias na solicitação.
Em aplicações gerais, as informações de autenticação são colocadas nos cabeçalhos da solicitação. Se você definir cabeçalhos um por um a cada solicitação, será muito demorado e trabalhoso. $httpProvider em angular fornece um interceptors interceptador através do qual um processamento unificado de todas as solicitações e respostas pode ser alcançado.
A maneira de adicionar um interceptador é a seguinte:
angular .module ('app') .config (['$ httpprovider', função ($ httpprovider) {$ httpprovider.intercept.push (httpintercept);}]); A definição de HttpInterceptor é a seguinte:
Angular .Module ('App') .Factory ('httpinterceptor', ['$ q', httpinterceptor]); função httpinterceptor ($ q) {return {// Antes da emissão da solicitação. } retornar config; }, // Ocorreu um erro ao solicitar que é emitido requesterror: function (err) {return $ q.reject (err); }, // resposta de resposta: function (res) {return res; }, // O erro de resposta retornado, inclusive quando o back-end retorna a resposta, o código de status HTTP de não 200 é definido: function (err) {return $ q.reject (err); }};}Os interceptores fornecem o processamento completo do ciclo de vida da solicitação à resposta de retorno, que geralmente pode ser usada para fazer o seguinte:
1. Adicione dados às solicitações emitidas uniformemente, como adicionar informações de autenticação
2. Manuseio de erro unificado, incluindo erros quando a solicitação é emitida (como a rede no lado do navegador não está conectada) e erros quando a resposta é retornada
3. Processamento de resposta unificada, como cache alguns dados, etc.
4. Exiba a barra de progresso da solicitação
No código de exemplo acima, quando localStorage inclui o token de valor, um valor token é adicionado na cabeça de cada solicitação.
Falha e manuseio
Geralmente, o back -end deve definir o código de status HTTP da resposta como 401 quando token falhar, para que ela possa ser tratada uniformemente no interceptor responseError :
ResponseError: function (err) {if (-1 === err.status) {// O servidor remoto não responde} else if (401 === err.status) {// O erro 401 é geralmente usado para falha de autenticação. Depende do erro lançado pelo back -end quando a autenticação falha} else if (404 === err.status) {// o servidor retorna 404} retornar $ q.reject (err);}Resumir
De fato, desde que o código de status retornado pelo servidor não seja 200, responseError será chamado. Aqui, o erro pode ser manuseado uniformemente e exibido.
O conteúdo acima está relacionado à verificação de login e identidade em aplicações de desenvolvimento angular. Espero que seja útil para todos aprenderem Angular.