在AngularJS应用中实现认证授权

在AngularJS应用中实现认证授权

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

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

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

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

实现登录

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

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来实现这个功能。下面的代码片段展示了其中一种实现思路:

$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对象。

app.factory("authenticationSvc", function() {
  var userInfo;

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

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

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只会被调用一次,我们需要在一个初始化函数中设置这个变量,代码如下所示:

    function init() {
      if ($window.sessionStorage["userInfo"]) {
        userInfo = JSON.parse($window.sessionStorage["userInfo"]);
      }
    }

init();

退出

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

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;
}

总结

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



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

时间: 2024-07-29 20:53:30

在AngularJS应用中实现认证授权的相关文章

[转].net中的认证(authentication)与授权(authorization)

本文转自:http://www.cnblogs.com/yjmyzz/archive/2010/08/29/1812038.html 注:这篇文章主要给新手看的,老手们可能会觉得没啥营养,就请绕过吧. "认证"与"授权"是几乎所有系统中都会涉及的概念,通俗点讲: 认证(authentication) 就是 "判断用户有没有登录?",好比windows系统,没登录就无法使用(不管你是用Administrator或Guest用户,总之要先正确登录后,

.net中的认证(authentication)与授权(authorization)

本文转自:http://www.cnblogs.com/yjmyzz/archive/2010/08/29/1812038.html 认证(authentication) 就是 "判断用户有没有登录?",好比windows系统,没登录就无法使用(不管你是用Administrator或Guest用户,总之要先正确登录后,才能进入系统). 授权(authorization) 就是"用户登录后的身份/角色识别",好比"管理员用户"登录windows后,

angularjs+webapi2 跨域Basic 认证授权(一)

如今的app,利用各种前端框架结合html5的混合开发模式已然盛极一时.其中ionic+angularjs更是如日中天.这种模式利用angularjs $http 请求数据api 以达到前后端分离深得人心.说到webapi 跨域和认证授权始终是不得不提的.这种现成的例子有很多,但我发现的要么是过于复杂,不利于第一次有效理解整个过程:要么就是侧重点比较单一,不好囊括:要么就是其中有些坑没有踩到,换个环境就一头雾水. 所以,我打算以最简单的实现方式最大限度地寻找其中的一些坑和注意点. 1.来看看我们

Spring Cloud 微服务中搭建 OAuth2.0 认证授权服务

在使用 Spring Cloud 体系来构建微服务的过程中,用户请求是通过网关(ZUUL 或 Spring APIGateway)以 HTTP 协议来传输信息,API 网关将自己注册为 Eureka 服务治理下的应用,同时也从 Eureka 服务中获取所有其他微服务的实例信息.搭建 OAuth2 认证授权服务,并不是给每个微服务调用,而是通过 API 网关进行统一调用来对网关后的微服务做前置过滤,所有的请求都必须先通过 API 网关,API 网关在进行路由转发之前对该请求进行前置校验,实现对微服

使用Owin中间件搭建OAuth2.0认证授权服务器

前言 这里主要总结下本人最近半个月关于搭建OAuth2.0服务器工作的经验.至于为何需要OAuth2.0.为何是Owin.什么是Owin等问题,不再赘述.我假定读者是使用Asp.Net,并需要搭建OAuth2.0服务器,对于涉及的Asp.Net Identity(Claims Based Authentication).Owin.OAuth2.0等知识点已有基本了解.若不了解,请先参考以下文章: MVC5 - ASP.NET Identity登录原理 - Claims-based认证和OWIN

[认证授权] 3.基于OAuth2的认证(译)

OAuth 2.0 规范定义了一个授权(delegation)协议,对于使用Web的应用程序和API在网络上传递授权决策非常有用.OAuth被用在各钟各样的应用程序中,包括提供用户认证的机制.这导致许多的开发者和API提供者得出一个OAuth本身是一个认证协议的错误结论,并将其错误的使用于此.让我们再次明确的指出: OAuth2.0 不是认证协议. 混乱的根源来自于在认证协议的内部实际上使用了OAuth,开发人员看到OAuth组件并与OAuth流程进行交互,并假设通过简单地使用OAuth,他们就

OAuth 2.0 认证授权

其实之前自己做的微信服务号的绑定登录也就是个OAuth认证授权 简单看下第三方使用OAuth做认证授权的过程:(取自网络,带图的大家应该都喜欢~) 第一步:用户登录第三方网站,例如使用qq登录. 第二步:点击登录后,会跳到qq平台提示输入用户名和密码. 第三步:如果用户名和密码正确,会提示是否接受授权,如果授权成功,第三方网站就能访问你的资源了,qq头像.用户名等 认证和授权过程(包括三方) 1.服务提供方,用户使用服务提供方来存储受保护的资源,如照片,视频,联系人列表. 2.用户,存放在服务提

[认证授权] 6.Permission Based Access Control

在前面5篇博客中介绍了OAuth2和OIDC(OpenId Connect),其作用是授权和认证.那么当我们得到OAuth2的Access Token或者OIDC的Id Token之后,我们的资源服务如何来验证这些token是否有权限来执行对资源的某一项操作呢?比如我有一个API,/books,它具有如下5个操作: POST /books 添加一本书 GET /books/{id} 获取一本书 PUT /books/{id} 更新一本书 DELETE /books/{id} 删除一本书 GET

k8s认证授权详解

理解认证授权 1.1 为什么要认证 想理解认证,我们得从认证解决什么问题.防止什么问题的发生入手. 防止什么问题呢?是防止有人入侵你的集群,root你的机器后让我们集群依然安全吗?不是吧,root都到手了,那就为所欲为,防不胜防了. 其实网络安全本身就是为了解决在某些假设成立的条件下如何防范的问题.比如一个非常重要的假设就是两个节点或者ip之间的通讯网络是不可信任的,可能会被第三方窃取,也可能会被第三方篡改.就像我们上学时候给心仪的女孩传纸条,传送的过程可能会被别的同学偷看,甚至内容可能会从我喜