在AngularJS应用中实现认证授权

在每一个严肃的应用中，认证和授权都是非常重要的一个部分。单页应用也不例外。应用并不会将所有的数据和功能都 暴露给所有的用户。用户需要通过认证和授权来查看应用的某个特定部分，或者在应用中进行特定的行为。为了在应用中对用户进行识别，我们需要让用户进行登录。

在用户管理方面，传统的服务器端应用和单页应用的实现方式有所不同，单页应用能够和服务器通信的方式只有AJAX。对于登录和退出来说也是如此。

负责识别用户的服务器端需要暴露出一个认证断电。单页应用将会把用户输入的信息发送到这个节点进行认证。在一个基于认证系统的典型token中，这 项服务用于在认证完毕之后获取一个token或者一个包含已登录用户的名字和角色信息的对象。客户端则需要在所有的安全API中获取这个token。

由于获取toekn的行为将会多次发生，我们最好将这个token存在客户端。在Angular中，我们可以将这个值存在一个服务中，因为服务在客 户端中是一个单体。但是，如果用户刷新了页面，服务中的值将会丢失。在这种情况下，最好将值存放在一个有浏览器提供的安全存储中，在这里我们要是用的是 sessionStorage，因为它在浏览器关闭时会自动被清空。

实现登录

我们现在来看一些代码。假设我们已经实现了所有的服务器端的逻辑，并且有一个叫做api/login的REST接口进行登录认证，它将返回一个token。我们来写一个简单的服务用于用户登录。在后面我们会为这个服务逐渐添加功能：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

app.factory("authenticationSvc", function($http, $q, $window) {
      var userInfo;

      function login(userName, password) {
        var deferred = $q.defer();

        $http.post("/api/login", {
          userName: userName,
          password: password
        }).then(function(result) {
          userInfo = {
            accessToken: result.data.access_token,
            userName: result.data.userName
          };
          $window.sessionStorage["userInfo"] = JSON.stringify(userInfo);
          deferred.resolve(userInfo);
        }, function(error) {
          deferred.reject(error);
        });

        return deferred.promise;
      }

      return {
        login: login
      };
    });

在实际的代码中，你可能会想要将存储的代码重构为一个单独的服务。在这里为了简单起见，我们只是将它放在他用一个服务中。这个服务可以被一个用于处理登录功能的控制器所用。

# 安全路由

我们需要在应用中设置一些安全路由。如果一个用户没有登录同时想要进入到某一个安全路由中，他应该被重定向到登录页。我们可以使用路由选项中的resolve来实现这个功能。下面的代码片段展示了其中一种实现思路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<pre class="brush:javascript;gutter:true;">$routeProvider.when("/", {
  templateUrl: "templates/home.html",
  controller: "HomeController",
  resolve: {
    auth: ["$q", "authenticationSvc", function($q, authenticationSvc) {
      var userInfo = authenticationSvc.getUserInfo();

      if (userInfo) {
        return $q.when(userInfo);
      } else {
        return $q.reject({ authenticated: false });
      }
    }]
  }
});

resolve块可以包含多个代码块，这些代码块将会在完成时返回promise对象。为了说明，上面代码中的auth并不在框架中，而是我们自己定义的。你可以根据你的需求来进行修改。

通过或者拒绝路由的原因有很多种。在这里的情形中，你可以在解析/拒绝一个promise的时候传递一个对象。我们在服务中还没有实现getLoggedInUser()方法。它是一个很简单的方法，能够从服务中返回loggedInUser对象。

1
2
3
4
5
6
7
<pre class="brush:javascript;gutter:true;">app.factory("authenticationSvc", function() {
  var userInfo;

  function getUserInfo() {
    return userInfo;
  }
});

通过上面的代码中的promise发送的想将会通过$rootScope进行广播。如果路由被解析，那么$routeChangeSuccess事件将会 被广播。然而，如果路由失败，那么事件$touteChangeError将会被广播。我们将监听$routeChangeError事件并将用户重定向 到登录页上。由于事件是在$rootScope层级上，最好在run函数中绑定事件处理器。

1
2
3
4
5
6
7
8
9
10
11
<pre class="brush:javascript;gutter:true;">app.run(["$rootScope", "$location", function($rootScope, $location) {
  $rootScope.$on("$routeChangeSuccess", function(userInfo) {
    console.log(userInfo);
  });

  $rootScope.$on("$routeChangeError", function(event, current, previous, eventObj) {
    if (eventObj.authenticated === false) {
      $location.path("/login");
    }
  });
}]);


# 处理页面刷新

当用户刷新页面时，服务将会失去现有状态。我们需要从浏览器的session storage中获取数据并将这些值赋值给loggerInUser变量。由于一个factory只会被调用一次，我们需要在一个初始化函数中设置这个变量，代码如下所示：

1
2
3
4
5
6
7
<pre class="brush:javascript;gutter:true;">    function init() {
      if ($window.sessionStorage["userInfo"]) {
        userInfo = JSON.parse($window.sessionStorage["userInfo"]);
      }
    }

init();


# 退出

当用户想要从应用中退出时，相应的API必须连同包含在请求头部中的token一起被调用。一旦用户退出，我们还需要清空sessionstorage中的数据。下面例子包含了一个退出函数，这个函数需要被添加到认证服务中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<pre class="brush:javascript;gutter:true;">function logout() {
  var deferred = $q.defer();

  $http({
    method: "POST",
    url: logoutUrl,
    headers: {
      "access_token": userInfo.accessToken
    }
  }).then(function(result) {
    $window.sessionStorage["userInfo"] = null;
    userInfo = null;
    deferred.resolve(result);
  }, function(error) {
    deferred.reject(error);
  });

  return deferred.promise;
}

<div class="content-wapper">
<div class="content">
<div class="left">
<div class="wrapper">
<div class="entry-content">

# 总结

单页应用的认证方式和传统web应用的认证方式非常不同。由于主要的工作都搬到了浏览器端，用户的状态也需要存储在客户端。重要的一点是要记住用户的状态也需要的服务器端保存和进行验证，因为骇客很可能慧聪客户端窃取用户的数据。

* * *

本文译自Implementing Authentication in Angular Applications，原文地址http://www.sitepoint.com/implementing-authentication-angular-applications/

</div></div></div></div></div></pre></pre></pre></pre></pre>

一、正向代理(Forward Proxy)

一般情况下，如果没有特别说明，代理技术默认说的是正向代理技术。关于正向代理的概念如下：

正向代理(forward)是一个位于客户端【用户A】和原始服务器(origin server)【服务器B】之间的服务器【代理服务器Z】，为了从原始服务器取得内容，用户A向代理服务器Z发送一个请求并指定目标(服务器B)，然后代理服务器Z向服务器B转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。如下图1.1

（图1.1）

从上面的概念中，我们看出，文中所谓的正向代理就是代理服务器替代访问方【用户A】去访问目标服务器【服务器B】

这就是正向代理的意义所在。而为什么要用代理服务器去代替访问方【用户A】去访问服务器B呢？这就要从代理服务器使用的意义说起。

使用正向代理服务器作用主要有以下几点：

## 1、访问本无法访问的服务器B，如下图1.2

##

## （图1.2）

##

## 我们抛除复杂的网络路由情节来看图1.2，假设图中路由器从左到右命名为R1,R2

## 假设最初用户A要访问服务器B需要经过R1和R2路由器这样一个路由节点，如果路由器R1或者路由器R2发生故障，那么就无法访问服务器B了。但是如果用户A让代理服务器Z去代替自己访问服务器B，由于代理服务器Z没有在路由器R1或R2节点中，而是通过其它的路由节点访问服务器B，那么用户A就可以得到服务器B的数据了。

## 现实中的例子就是“FQ”。不过自从VPN技术被广泛应用外，“FQ”不但使用了传统的正向代理技术，有的还使用了VPN技术。

##

## 2、加速访问服务器B

这种说法目前不像以前那么流行了，主要是带宽流量的飞速发展。早期的正向代理中，很多人使用正向代理就是提速。还是如图1.2

假设用户A到服务器B，经过R1路由器和R2路由器，而R1到R2路由器的链路是一个低带宽链路。而用户A到代理服务器Z，从代理服务器Z到服务器B都是高带宽链路。那么很显然就可以加速访问服务器B了。

##

## 3、Cache作用

##

Cache（缓存）技术和代理服务技术是紧密联系的（不光是正向代理，反向代理也使用了Cache（缓存）技术。还如上图所示，如果在用户A访问服务器B某数据J之前，已经有人通过代理服务器Z访问过服务器B上得数据J，那么代理服务器Z会把数据J保存一段时间，如果有人正好取该数据J，那么代理服务器Z不再访问服务器B，而把缓存的数据J直接发给用户A。这一技术在Cache中术语就叫Cache命中。如果有更多的像用户A的用户来访问代理服务器Z，那么这些用户都可以直接从代理服务器Z中取得数据J，而不用千里迢迢的去服务器B下载数据了。

##

## 4、客户端访问授权

##

这方面的内容现今使用的还是比较多的，例如一些公司采用ISA SERVER做为正向代理服务器来授权用户是否有权限访问互联网，挼下图1.3

##

## （图1.3）

## 图1.3防火墙作为网关，用来过滤外网对其的访问。假设用户A和用户B都设置了代理服务器，用户A允许访问互联网，而用户B不允许访问互联网（这个在代理服务器Z上做限制）这样用户A因为授权，可以通过代理服务器访问到服务器B，而用户B因为没有被代理服务器Z授权，所以访问服务器B时，数据包会被直接丢弃。

## 5、隐藏访问者的行踪

如下图1.4 我们可以看出服务器B并不知道访问自己的实际是用户A，因为代理服务器Z代替用户A去直接与服务器B进行交互。如果代理服务器Z被用户A完全控制（或不完全控制），会惯以“肉鸡”术语称呼。

##

## （图1.4）

##

## 我们总结一下 正向代理是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。

##

# 二、反向代理（reverse proxy）

# 反向代理正好与正向代理相反，对于客户端而言代理服务器就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间(name-space)中的内容发送普通请求，接着反向代理将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端。

使用反向代理服务器的作用如下：

## 1、 保护和隐藏原始资源服务器

如下图2.1

##

（图2.1）

用户A始终认为它访问的是原始服务器B而不是代理服务器Z，但实用际上反向代理服务器接受用户A的应答，从原始资源服务器B中取得用户A的需求资源，然后发送给用户A。由于防火墙的作用，只允许代理服务器Z访问原始资源服务器B。尽管在这个虚拟的环境下，防火墙和反向代理的共同作用保护了原始资源服务器B，但用户A并不知情。

## 2、 负载均衡

如下图2.2