我将首先解释我所说的"后端控制"answers"前端控制"是什么意思。
我已经用php框架开发web应用程序很多年了。它总是由php后端处理所有的逻辑，并将"视图"发送给客户端。这就是我所说的"后端控制web应用程序"。现在我明白了我称之为"前端控制应用程序"的关注点分离的好处，在后端从不向客户端发送html视图。它只发送数据，视图完全由客户端处理(angularjs, vuejs，…)。这使得相同的后端(现在只是一个REST API)最终也可以被移动应用程序使用。
所以现在我解释了我所说的"后端控制的web应用程序"answers"前端控制的web应用程序"，并解释了我理解前端控制的web应用程序的一些优点。现在我将提到我对此的一些疑问，我期待这些疑问的答案，因为我确信有我没有意识到的答案:
在后端控制的web应用程序中，表单是跨站点请求伪造保护的(至少当你使用一个体面的后端框架时)。在后台，一个令牌被添加到会话中，以确认请求来自相同的应用程序表单。如何在前端控制的应用程序中做到这一点?
我看到过前端控制的应用程序对同一个页面发出多个请求(一个请求身份验证，一个请求每个组件(比如网页的一部分))。另一方面，我们知道"browserify"我们的资产(css和js)是一个很好的实践，以减少对服务器的请求数量。因此，一方面，向后端发出尽可能少的请求是一种很好的做法，但另一方面，对于前端控制的应用程序，看到一个页面有5个请求是很常见的，例如向后端发出请求。如果它是一个后端控制的应用程序，那么同样的页面只需要一个请求。
谢谢
-
我再次研究了csrf和IIUC, xhr对csrf更好，因为:
- 现代浏览器自动将
origin标头添加到所有xhr中，从而阻止来自意外域的所有请求(与服务器端的allow-origin配置一起)。 -
当在服务器端渲染页面时，我们可以通过手动在js代码中添加csrf令牌来做更多的事情(稍后以xhr的形式发送请求)。js代码中的令牌是攻击者无法获取的。EDIT:这对于单页应用程序不是唯一的，我了解到传统的服务器渲染网站可以通过在阅读维基百科的
Synchronizer token pattern章节后在表单的隐藏字段中编写令牌来实现同样的功能。我想到的不是<input type="hidden" name="csrftoken" value="..." />，而是<script>var csrfToken={{server.token()}}</script>({{}}是服务器端模板)。前者在表单发布时使用，我的是在js代码发送xhr时使用。我的想法是混合Synchronizer token pattern章节和维基百科页面上的下一章。通过这些方法，如果我们的站点没有XSS，攻击者将无法获得session/page/js中的令牌，并且他欺骗用户浏览器发送的请求将在没有令牌的情况下失败。这导致:现代单页应用程序的XHR 比传统的web应用程序更重，传统的web应用程序利用完整的页面服务器端渲染，在不同场合使用js操纵的视图更改(使用XHR)。因此，更安全。
- 现代浏览器自动将
-
1个请求肯定比5个好，如果只是为了请求计数。这里我们做了一个权衡:通过添加一些流量来加载页面，我们获得:
- 如OP所述，服务器接口可被移动应用重用，因为它们返回纯数据，而不是将数据与网页混合的html。
-
更好地分离前端和后端关注。后端开发人员编写更小的单功能接口。对于前端开发人员来说更好的是:视图、样式、交互逻辑脚本(正如我们在
.vue文件中看到的)都被组织在组件中，需要担心的事情更少，我们可以更快乐。