添加动态的内容
目前我们已经有了一个应用程序,硬编码了一句问候语在里面。这对学习如何把这些凑到一起很有帮助,不过实际上我们期望的是来自于后台服务器的内容,因此我们可以创建一个HTTP端点,然后用这个来抓取到一句问候语。在你的启动类 (SpringSecurityAndAngularJsBasicApplication)中, 加上 @RestController 注解并定义一个新的 @RequestMapping:
运行应用程序并在浏览器中 "http://localhost:8080/resource" 尝试,你会发现它默认是受到保护的,输入用户、密码之后,如下图
从Angular加载一个动态资源
那么我们来在浏览器中抓取这条消息。修改“home”控制器,让它使用XHR加载受到保护的资源:
hello.js
我们注入了一个由Angular作为核心功能提供的$http服务, 并被用来GET到我们的资源。 Angular 会为我们将JSON从响应消息体传递回调用成功的回调函数。
再一次运行应用程序(或者只要在浏览器中刷新主页), 你就会看到带有唯一ID的动态消息了。因此,尽管资源是受到保护的,而且你也不能直接通过curl获取到,但浏览器还是有能力访问其内容的。不到一百行代码,我们就有了一个受保护的单页面应用程序!
你也许需要强制让浏览器在你修改了静态资源之后进行刷新。在Chrome(还有Firefox的一个插件中)你可以使用“开发者工具”(F12),而那也许就足够了。或者你可能得使用CTRL+F5了。
它是如何运作的?
如果你使用一些开发者工具(常常是使用F12开启的,Chrome里面默认会运作,而在Firefox中则可能需要一个插件),浏览器和后台之间的交互就可以在你的浏览器中被看见。这里有一个总结:
你可能不会见到401,因为浏览器会就主页的架子啊当做一次单独的交互, 而你也许会见到两次针对 "/resource" 的请求,因为这个要有一次CORS(跨域资源共享)的过程。
更近一点看所有的请求,你会发现它们所有的都带有一个 "Authorization" 消息头,像下面这样:
每次请求浏览器都要发送用户名和密码 (因此记得在生产环境中一定要使用HTTPS)。“Angular“跟这个没有任何关系,所以你用不用JavaScript框架它都会起作用。
还有哪不对头呢?
表面上看起来我们做的相当不错,简洁,易于实现,所有的数据都受到一个密码的保护,而且如果我们改了前端或者后台技术,它也该还是会起作用。但是有一些问题。
- 基础的认证只限于用户名和密码认证。
- 认证UI显得很普通,有点丑陋(浏览器对话框)。
- 对于跨站的请求伪造 (CSRF)缺少防护。
CSRF 在我们的应用程序中并不真的是一个问题,因为它只需要GET到后台资源就行了(例如,在服务器中没有状态发生改变)。一旦你的应用程序中要有 POST, PUT 或者 DELETE 的话,那它就再也不受任何合理的现代措施的保护了。
在这个系列的下一节我们会扩展应用程序,使用基于表单的认证, 它会比HTTP更多一些灵活性。一旦我们有了一个表单,我们就需要CSRF防护了,而对此Spring Security和Angular都有一些不错的开箱即用的功能特性。剧透一下:我们在HttpSession会需要用到。
添加动态的内容
目前我们已经有了一个应用程序,硬编码了一句问候语在里面。这对学习如何把这些凑到一起很有帮助,不过实际上我们期望的是来自于后台服务器的内容,因此我们可以创建一个HTTP端点,然后用这个来抓取到一句问候语。在你的启动类 (SpringSecurityAndAngularJsBasicApplication)中, 加上 @RestController 注解并定义一个新的 @RequestMapping:
运行应用程序并在浏览器中 "http://localhost:8080/resource" 尝试,你会发现它默认是受到保护的,输入用户、密码之后,如下图
从Angular加载一个动态资源
那么我们来在浏览器中抓取这条消息。修改“home”控制器,让它使用XHR加载受到保护的资源:
hello.js
我们注入了一个由Angular作为核心功能提供的$http服务, 并被用来GET到我们的资源。 Angular 会为我们将JSON从响应消息体传递回调用成功的回调函数。
再一次运行应用程序(或者只要在浏览器中刷新主页), 你就会看到带有唯一ID的动态消息了。因此,尽管资源是受到保护的,而且你也不能直接通过curl获取到,但浏览器还是有能力访问其内容的。不到一百行代码,我们就有了一个受保护的单页面应用程序!
你也许需要强制让浏览器在你修改了静态资源之后进行刷新。在Chrome(还有Firefox的一个插件中)你可以使用“开发者工具”(F12),而那也许就足够了。或者你可能得使用CTRL+F5了。
它是如何运作的?
如果你使用一些开发者工具(常常是使用F12开启的,Chrome里面默认会运作,而在Firefox中则可能需要一个插件),浏览器和后台之间的交互就可以在你的浏览器中被看见。这里有一个总结:
你可能不会见到401,因为浏览器会就主页的架子啊当做一次单独的交互, 而你也许会见到两次针对 "/resource" 的请求,因为这个要有一次CORS(跨域资源共享)的过程。
更近一点看所有的请求,你会发现它们所有的都带有一个 "Authorization" 消息头,像下面这样:
每次请求浏览器都要发送用户名和密码 (因此记得在生产环境中一定要使用HTTPS)。“Angular“跟这个没有任何关系,所以你用不用JavaScript框架它都会起作用。
还有哪不对头呢?
表面上看起来我们做的相当不错,简洁,易于实现,所有的数据都受到一个密码的保护,而且如果我们改了前端或者后台技术,它也该还是会起作用。但是有一些问题。
- 基础的认证只限于用户名和密码认证。
- 认证UI显得很普通,有点丑陋(浏览器对话框)。
- 对于跨站的请求伪造 (CSRF)缺少防护。
CSRF 在我们的应用程序中并不真的是一个问题,因为它只需要GET到后台资源就行了(例如,在服务器中没有状态发生改变)。一旦你的应用程序中要有 POST, PUT 或者 DELETE 的话,那它就再也不受任何合理的现代措施的保护了。
在这个系列的下一节我们会扩展应用程序,使用基于表单的认证, 它会比HTTP更多一些灵活性。一旦我们有了一个表单,我们就需要CSRF防护了,而对此Spring Security和Angular都有一些不错的开箱即用的功能特性。剧透一下:我们在HttpSession会需要用到。