今天完成的事：完成了路由守卫的设置

明天要完成的事：打包并通过审核

难题：

但是我没理解的事是：师兄后面问我为什么不用cookie和本地储存时，我一下感觉蒙了，确实是的在很多时候为什么有简单的方法不用呢？感觉自己的思维和基础都不是很好接下来的时间还是要好好补。

收获：

路由器可以支持多种守卫接口：

• 用CanActivate来处理导航到某路由的情况。

• 用CanActivateChild来处理导航到某子路由的情况。

• 用CanDeactivate来处理从当前路由离开的情况.

• 用Resolve在路由激活之前获取路由数据。

• 用CanLoad来处理异步导航到某特性模块的情况。

在分层路由的每个级别上，你都可以设置多个守卫。 路由器会先按照从最深的子路由由下往上检查的顺序来检查 CanDeactivate() 和 CanActivateChild() 守卫。 然后它会按照从上到下的顺序检查 CanActivate() 守卫。 如果特性模块是异步加载的，在加载它之前还会检查 CanLoad() 守卫。 如果任何一个守卫返回 false，其它尚未完成的守卫会被取消，这样整个导航就被取消了。

现在“危机中心”的每个路由都是对所有人开放的。这些新的管理特性应该只能被已登录用户访问。

你可以在用户登录之前隐藏这些链接，但这样会有点复杂并难以维护。

你可以换种方式：写一个 CanActivate() 守卫，将正在尝试访问管理组件匿名用户重定向到登录页。

这是一个通用的守卫（你可以假设另外一些特性区也要求已认证过的用户才能访问），所以你可以在 auth 目录下生成一个 AuthGuard。

虽然它不会真的进行登录，但足够让你进行这个讨论了。 它有一个 isLoggedIn 标志，用来标识是否用户已经登录过了。 它的 login 方法会仿真一个对外部服务的 API 调用，返回一个可观察对象（observable）。在短暂的停顿之后，这个可观察对象就会解析成功。 redirectUrl 属性将会保存在 URL 中，以便认证完之后导航到它。

这就修改 AuthGuard 来调用它。

注意，你把 AuthService 和 Router 服务注入到构造函数中。 你还没有提供 AuthService，这里要说明的是：可以往路由守卫中注入有用的服务。

该守卫返回一个同步的布尔值。如果用户已经登录，它就返回 true，导航会继续。

这个 ActivatedRouteSnapshot 包含了即将被激活的路由，而 RouterStateSnapshot 包含了该应用即将到达的状态。 你应该通过守卫进行检查。

如果用户还没有登录，你就会用 RouterStateSnapshot.url 保存用户来自的 URL 并让路由器导航到登录页（你尚未创建该页）。 这间接导致路由器自动中止了这次导航，checkLogin() 返回 false 并不是必须的，但这样可以更清楚的表达意图。

然后再这个里面有个方法将返回值从false变成true，但是我没理解的事是：师兄后面问我为什么不用cookie和本地储存时，我一下感觉蒙了，确实是的在很多时候为什么有简单的方法不用呢？感觉自己的思维和基础都不是很好接下来的时间还是要好好补。