这篇文章适合已经初步了解MongoDb, Express, Angular, Node.js, rxjs，需要一个小项目来练手的同学。

这篇文章我们分析这个实例：

MEAN with Angular 2 - User Registration and Login Example & Tutorial

这是一个全栈的登录认证例子，还包括注册、删除账户等功能，技术栈使用的是MEAN。代码清晰易懂。我在这里只总结一下登陆逻辑的要点。

前端：

1. 如何保持登录状态？

我们使用HTML5的localstorage来存储最近登陆的账户信息。当AuthGuard检查访问权限的时候，它会直接看看localstorage中有没有账户信息。如果有，则允许访问，反之则跳转到login页面。

进一步想想，我们是什么时候用localstorage来存进账户信息的呢？答案就在AuthenticationService中。我们登陆成功的时候，服务器会返回给我们账户信息对象，这个对象含有_id，username，firstName，lastName和token，我们就是这个时候把这个账户信息对象存进localstorage里的。

_id和token是什么？这并不是我们注册账号的时候所输入的东西啊！

_id是我们在注册账户的时候，后端数据库所生成的唯一标识，不同账户的_id是不同的。

token是令牌、口令的意思，服务端看到了令牌，就可以确认请求发送者的身份（从它解析出账户的_id）。每次客户端的UserService给服务器发出请求的时候，都会发送加上'Authorization': 'Bearer ' + token这个请求头。服务器每次收到token以后可以从中解密出用户的_id，如果解密出的_id与请求发送着申明的账户匹配，则服务器就可以知道，这个请求确实是这个_id的用户所发过来的。（token存在的意义就是让Peter只能以Peter的_id发请求，而无法冒充Mary发请求，我会在这篇文章的后端部分解释token是怎么生成的，有关数字签名的概念和意义，我会有后续的文章来专门解释）

2. 如何在登陆以后跳转到本来要访问的页面？（跨页面传递数据）

AuthGuard在跳转到login页面的时候同时会传递一个{ queryParams: { returnUrl: state.url }}（state.url是我们本来要访问的页面），在login component初始化的时候会从路由中取出这个returnUrl，并存在登陆组件中，一旦登陆成功，则跳转到returnUrl。

3. 如何控制Alert通知是否在路由跳转以后依旧显示？

AlertService的一个设计亮点就是可以控制下一次路由跳转以后，通知是否依旧显示。默认时keepAfterNavigationChange为false，当路由开始跳转的时候，AlertService会判断keepAfterNavigationChange，如果为false，则推送一个空的消息给AlertComponent，让AlertComponent的message变成undefined；如果路由跳转时keepAfterNavigationChange为true，则改为false，并且不推送消息给AlertComponent，从而AlertComponent的message保持原状。因此，当我们使用AlertService的success和error方法时，就可以改变keepAfterNavigationChange的值，从而控制Alert是否在路由跳转以后依旧显示。

后端

1. 后端如何验证请求发送者的身份？

在server.js中，我们看到这样一句代码：

// use JWT auth to secure the api

app.use(expressJwt({ secret: config.secret }).unless({ path: ['/users/authenticate', '/users/register'] }));

其中expressJwt是一个外部模块express-jwt，它是一个express中间件，将它放在bodyParser之后，路由之前，它就可以像防火墙一样过滤掉身份认证不合法的请求。

当然，有一些路径是不需要认证的，比如/users/authenticate和/users/register，登陆、注册这些页面是所有人都可以访问的，所以要把他们用unless({path:[]})排除在外。

这个中间件会提取请求头的authorization字段（还记得我们之前在客户端发送的Authorization请求头吗，请求头字母都会转换成小写哦），获得客户端的token，用config.secret解密，然后检验这个token是否被篡改过，如果没有被篡改过，就可以解析出token中蕴藏的信息（在这个例子中就是_id），然后放在req.user中。在我们后续处理路由的时候就可以使用req.user里面的信息了。

2. token是怎么生成的？

还记得在前端部分，我们说过token是在登录认证成功以后，服务器返回的信息之一。在服务器的user.service.js的authenticate方法中，我们可以看到token是怎么产生的

token: jwt.sign({ sub: user._id }, config.secret)

其中jwt是一个外部模块node-jsonwebtoken，用于将数据签名。token就是{ sub: user._id }被签名以后生成的！这个例子有一个坑点，user._id这个值对应的键是sub而不是_id，因此我们在后面如果要得到用户的_id就要用req.user.sub而不是req.user._id。

3.数据库操作与controller分离

在后端，有两个很相似的模块，users.controller.js和user.service.js，controller规定了在导航到某个路由以后直接执行的函数，controller中的函数负责从req中取出操作所需的参数（比如认证操作就需要取出req.body.username和req.body.password），然后传递给user.service.js的函数，获得操作结果以后，通过res返回。

user.service.js中的函数则直接与数据库打交道，完成基本的任务并将操作结果返回。

3.数据库操作坑点

我们发现，在user.service.js中，有时候根据id使用数据库直接使用_id，有时候却要传入{ _id: mongo.helper.toObjectID(_id) }。原来mongoskin这个模块有两种使用id的方式，比如说

collection.findById(id, ...)

= collection.find({_id: mongo.helper.toObjectID(id)}, ...)