[b]前言[/b] 由于 Angular 是单页应用，会在一开始，就把大部分的资源加载到浏览器中，所以就更需要注意验证的时机，并保证只有通过了验证的用户才能看到对应的界面。 本篇文章中的身份验证，指的是如何确定用户是否已经登陆，并确保在每次与服务器的通信中，都能够满足服务器的验证需求。注意，并不包括对具体是否具有某一个权限的判断。 对于登陆，主要是接受[b]用户的用户名密码输入[/b]，[b]提交到服务器进行验证[/b]，[b]处理验证响应[/b]，[b]在浏览器端构建身份验证数据[/b]。 [b]实现身份验证的两种方式[/b] 目前，实现身份验证的方法，主要有两个大类： [b]Cookies[/b] 传统的浏览器网页，都是使用 Cookies 来验证身份，实际上，浏览器端的应用层里，基本不用去管身份验证的事情，Cookies 的设置，由服务器端完成，在提交请求的时候，由浏览器自动附加对应的 Cookies 信息，所以在 JavaScript 代码中，不需要为此编写专门的代码。但每次请求的时候，都会带上全部的 Cookies 数据， 随着 CDN 的应用，移动端的逐渐兴起， Cookies 越来越不能满足复杂的、多域名下的身份验证需求。 [b]密钥[/b] 实际上基于密钥的身份验证并不是最近才兴起，它一直存在，甚至比 Cookies 历史更长。当浏览器在请求服务器的时候，将密钥以特定的方式附加在请求中，比如放在请求的头部（ headers ）。为此，需要编写专门的客户端代码来管理。 最近出现的基于 JSON 的 Web 密钥[code]（JSON Web Token）[/code]标准，便是典型的使用密钥来实现的身份验证。 在 Web 应用中，如果是构造 API ，则应优先考试使用密钥方式。 [b]处理登陆[/b] 登陆是身份验证第一步，通过登陆，才能够组织起来对应的身份验证数据。 [b]需要使用单独的登陆页吗？[/b] 登陆页的处理，有两种方式： [b]单独的登陆页[/b]，在登陆完成后，跳转到单页应用之中，这样做可以对单页应用的资源进行访问控制，防止非登陆用户访问，适合后台或者管理工具的应用场景。但实际上降低了单页应用的用户体验 [b]在单页应用之内执行登陆[/b]，这样更符合单页应用的设计理念，比较适合大众产品的场景，因为恶意的人总是能够拿到你单页应用的前端代码 [b]单独的登陆页[/b] 一般情况下，使用单独的登陆页的目的在于保护登陆后跳转的页面不被匿名用户访问。因此，在登陆页里，构造一个表单，直接采用传统的表彰提交方式[b]（非 Ajax），[/b]后端验证用户名密码成功后，输出登陆后单面应用页面的 HTML 。 在这种情况下，可以直接将身份验证信息放在输出的 HTML 里，比如，可以使用[b]Jade [/b]构造一个这样的页面： 后端在用户名密码验证成功之后，可以采用如下的方式来渲染输出 HTML ： Angular 应用一启动，便可以进行需要使用身份验证的通信。而且还保证了只有登陆成功的用户才可以进入这个页面。 [b]单页应用内登陆的组织[/b] 对于多视图的 Angular 应用，一般会采用路由，在页面之内，一般有固定的侧边栏菜单，或者顶部导航菜单，正文区域由路由模块来控制。 下面的示例代码，使用的是 Angular Material 来组织页面，路由模块使用的是 ui-router 。在应用打开的时候，有专门的加载动画，加载完成之后，显示的页面，使用 [code]AppController[/code] 这个控制器，对于没有登陆的用户，会显示登陆表单，登陆完成之后，页面分为三大部分，[b]一是顶部面包屑导航[/b]，[b]二是侧边栏菜单[/b]，另外就是[b]路由控制的正文部分[/b]。 [b]代码如下：[/b] 对于 Loading 动画，是在[code] AppController [/code]之外的，可以在 [code]AppController[/code] 的代码中，对其进行隐藏。这样达到了所有 CSS / JavaScript 加载完成之后 Loading 就消失的目的。 [code]AppController [/code]中有一个变量 [code]isUserAuth[/code] ，初始化的时候是[code] false[/code] ，当本地存储的会话信息验证有效，或者登陆完成之后，这个值便会置为 [code]ture [/code]，由于 [code]ng-if[/code] 的控制，便可以实现隐藏登陆表单、显示应用内容的目的。要注意，这里只有使用 [code]ng-if[/code] 而不是 [code]ng-show/ng-hide[/code] ，前者才会真正的删除和增加 DOM 元素，而后者只是修改某个 DOM 元素的 CSS 属性，这点很重要，只有这样，才能够保证登陆完成之后，再加载单页应用中的内容，防止还没有登陆，当前路由中的控制器代码就直接执行了。 [b]为什么客户端也要加密密码[/b] 一个比较理想的基于用户名和密码的登陆流程是这样的：     1.浏览器端获取用户输入的密码，使用 MD5 一类的哈希算法，生成固定长度的新密码，如 [code]md5(username + md5(md5(password))) [/code]，再将密码哈希值和用户名提交给后端     2.后端根据用户名获取对应的盐，使用用户名和密码哈希值，算出一个密文，根据用户名和密文去数据库查询     3.如果查询成功，则生成密钥，返回给浏览器，并执行第 4 步     4.后端生成新的盐，根据新的盐和浏览器提交的密码哈希值，生成新的密文。在数据库中更新盐和密文 可能有 80% 的人无法理解为什么要把一个登陆做得这么复杂。这可能要写一篇专门的文章才解释得清楚。在这里先解释一下为什么浏览器端要对密码做哈希，原因如下：     1.从源头上保护用户的密码，保证只有做按键记录才可以拿到用户的原始密码     2.就算网络被窃听，又没有使用 https ，那么被偷走的密码，也只是哈希之后的，最多影响用户在这个服务器里的数据，而不影响使用相同密码的其它网站     3.就算是服务器的所有者，都无法获取用户的原始密码 这种做法，使得用户的最大风险，也只是当前这个应用中的数据被窃取。不会扩大损失范围，绝不会出现 CSDN 之流的问题。 [b]登陆成功的通知[/b] 对于有些应用，并不是所有的页面都需要用户登陆的，可能是进行某些操作的时候，才需要登陆。在这种情况下，登陆完成之后，必须要通知整个应用。这可以使用广播这个功能。 [b]简易代码如下：[/b] 在其它的控制器中，便可以监听这个广播，并执行登陆成功之后需要进行的操作，如获取列表或者详情： [b]身份验证信息[/b] 登陆成功之后，服务器返回了密钥，之后的 API 请求都需要带上密钥，而且请求返回的响应，还需要检查是否是关于身份信息失效的错误。这一系列的工作比较繁琐，应该是自动完成才行。 [b]保存[/b] 密钥的保存，大概有如下几个办法：    [b] 1.Cookies：[/b]前面已经提到了，这个并不推荐使用。同时，它还有最大 4k 的限制    [b]2.sessionStorage：[/b]tab 页内有效，一旦关闭，或者打开了新的 tab 页，sessionStorage 是不能共享的    [b]3.localStorage：[/b]较为理想的存储方式，除非清理浏览器数据，否则 localStorage 存储的数据会一直存在    [b]4.Angular 单例 Service：[/b]存储在应用之内得话，刷新后数据会丢失，当然也不能 tab 页之间共享 比较好的办法是，身份验证信息存储在 localStorage 里，但在应用启动时，初始化到 Angular 的单例 Service 中。 [b]在请求中加入身份验证信息[/b] 身份验证信息的目的，是为了向服务器表明身份，获取数据。所以，在请求中需要附加身份验证信息。 一般的应用中，身份验证信息都是放在请求的 headers 头部中。如果在每次请求的时候，一一设置 headers ，那就太费时费力了。Angular 中的 [code]$httpProvider [/code]提供了一个拦截器[code] interceptors [/code]，通过它可以实现对每一个请求和响应的统一处理。 添加拦截器的方式如下： [code]HttpInterceptor[/code] 的定义方式如下： 拦截器提供了对发出请求到返回响应的全生命周期处理，一般可以用来做下面几个事情：     1.统一在发出的请求中添加数据，如添加身份验证信息     2.统一处理错误，包括请求发出时出的错（如浏览器端的网络不通），还有响应时返回的错误     3.统一处理响应，比如缓存一些数据等     4.显示请求进度条 在上面的示例代码中，当 [code]localStorage[/code] 中包括[code] token [/code]这个值时，就在每一个请求的头部，添加一个 [code]token [/code]值。 [b]失效及处理[/b] 一般的，后端应该在 [code]token [/code]验证失败时，将响应的 http 状态码设置为 401 ，这样，在拦截器的[code] responseError [/code]中便可以统一处理： [b]总结[/b] 其实，只要服务器返回的状态码不是 200 ，都会调用 [code]responseError [/code]，可以在这里，统一处理并显示错误。 以上内容是关于Angular开发应用中的登陆与身份验证的相关知识，希望对大家学习Angular有所帮助。