后端与前端控制的 Web 应用程序

Question

我先解释一下我所说的“后端控制”和“前端控制”。

多年来，我一直在使用 php 框架开发 Web 应用程序。它总是由 php 后端处理所有逻辑并将“视图”发送给客户端。这就是我所说的“后端控制的 Web 应用程序”。

现在我了解了我称之为“前端控制的应用程序”的关注点分离的优势，在这种应用程序中，后端从不将 html 视图发送给客户端。它只发送数据，视图完全由客户端处理（angularjs，vuejs，...）。这使得移动应用程序最终也可以使用相同的后端（现在只是一个 REST API）。

所以现在我解释了我所说的“后端控制的 Web 应用程序”和“前端控制的 Web 应用程序”的含义，并解释了我理解前端控制的 Web 应用程序的一些优点。现在我将提到我对此的一些疑问，我期待这些疑问的答案，因为我确信有些答案是我不知道的：

1. 在后端控制的 Web 应用程序中，表单受跨站点请求伪造保护（至少在您使用体面的后端框架时）。在后台，一个令牌被添加到会话中，以确认请求来自同一个应用程序表单。您如何在前端控制的应用程序中做到这一点？

2. 我看到前端控制的应用程序对同一页面发出多个请求（一个身份验证请求，一个对每个组件的请求（例如网页的部分））。另一方面，我们知道“浏览”我们的资产（css 和 js）以减少对服务器的请求数量是一种很好的做法。因此，一方面向后端发出尽可能少的请求是一种好习惯，但另一方面，对于前端控制的应用程序，看到一个页面有 5 个请求（例如对后端）是很常见的-结尾。如果同一页面是后端控制的应用程序，则该页面只需要 1 个请求。

谢谢

Answer 1

1. 我再次研究了 csrf 和 IIUC，XHR 比 csrf 更好，因为：

   • 现代浏览器会自动将 origin 标头添加到所有 XHR，这会阻止来自意外域的所有请求（以及服务器端的 allow-origin 配置）。

   • 我们可以通过在服务器端渲染页面时手动将 csrf 标记添加到 js 代码中来做更多事情（稍后在 XHR 中与请求一起发送）。攻击者无法获取 js 代码中的令牌。 编辑：这对于单页应用程序来说并不是唯一的，我了解到传统的服务器渲染网站可以通过在阅读 Synchronizer token pattern 后将令牌写入表单的隐藏字段中来做同样的事情wikipedia的章节。而不是<input type="hidden" name="csrftoken" value="..." />，我想到了<script>var csrfToken={{server.token()}}</script>（{{}}是服务器端模板）。前者在表单发布时使用，我的在js代码发送XHR时使用。我的想法是混合Synchronizer token pattern 章节和维基百科页面中的下一个章节。通过这些方式，如果我们的网站是无 XSS 的，攻击者将无法获取 session/page/js 中的令牌，并且他欺骗用户浏览器发送的请求将在没有令牌的情况下失败。

     这导致：现代单页应用程序的 XHR 重 比传统的 Web 应用程序，后者利用全页服务器端渲染和 js 操纵的视图更改（使用 XHRs）在不同的场合。因此，更安全。

2. 1 个请求肯定比 5 个要好，如果只是为了请求计数的话。在这里我们进行权衡：通过添加一些流量来加载页面，我们获得：

   • 正如 OP 所述，移动应用程序可重复使用服务器接口，因为它们返回纯数据，而不是将数据与网页混合的 html。

   • 更好地分离前端和后端的关注点。后端开发人员编写更小的单一功能接口。对前端开发人员来说甚至更好：视图、样式、交互逻辑脚本（正如我们在.vue 文件中看到的）都组织在组件中，更少的事情需要担心，我们可以更快乐。

     因此，我认为这笔交易是完全值得的。