SPA架构问题

Question

本文旨在开始深入讨论Web的单页应用程序.在大多数有关该主题的资源中,有些问题似乎没有明确的答案.他们在我的脑海里

1. 授权和身份验证.当整个Web应用程序位于客户端上时,它可以在其任何功能中调用服务器,甚至是用户无权访问的那些功能.用户无法看到菜单的事实并不妨碍该人调用java脚本函数.这在MVC应用程序中很容易处理,例如,通过使用控制器来验证基于cookie的特定功能的用户权限.但是,一些SPA应用程序只使用单个控制器与Breeze或Web Api,这使得授权服务器端不可能.
2. 客户端上的内存管理对于小型示例应用程序,这不是问题,但想象一下具有100个屏幕的应用程序或具有单个屏幕的应用程序,其在一天的过程中提取数千条记录.使用持久性缓存可以想象大量内存问题,尤其是在手机或平板电脑等内存不足的设备不足的情况下.一组开发人员如何在没有明确处理内存管理愿景的情况下拥有SPA路线？
3. 三层部署某些IT部门永远不会允许具有连接字符串的应用程序连接到位于前端Web服务器上的数据库.我见过的每个SPA演示都是这样的结构,包括Breeze或Web Api.
4. 不引人注目的验证.它需要开发人员使用MVC部分视图和控制器而不仅仅是HTML文件,这似乎是面对SPA概念的,而它提供了一种非常强大的方法,可以轻松地将验证和UI结合到Web应用程序中.
5. 在url中公开基于主整数的键.
   这在OWASP中是不可取的.因此,SPA应用程序"似乎"定位于安全要求较少且功能集较少的区域.你怎么看？

谢谢.

Answer 1

@Sergey - 我认为这对StackOverflow来说太宽泛了.SO不是讨论论坛; 这是一个特定答案的地方.因此,虽然您的问题可能是有效的,但我认为您不应该对此采取深刻的实质性回应抱太大希望.

我可以用尽可能最友好的方式补充一下,你那些彻底,不受支持和否定的陈述会让你看起来像个巨魔.你是谢尔盖,你不是巨魔吗？

关于你事实上真正关心的可能性,我提供了一些快速反应,特别是因为它们与Breeze有关.

1. 授权.在Web API中,您可以在方法级别进行授权.ApiController基类有一个User返回的属性IPrincipal.因此,无论您有一个控制器还是多个(如果需要,您可以在Breeze中使用多个控制器),粒度是方法级别,而不仅仅是类级别.

2. 内存管理.桌面开发人员多年来一直在应对这种担忧.如果您始终开发过程生命周期短暂的传统Web应用程序,这可能会让您感到惊讶.但对于我们这些在桌面技术(如WinForms,WPF和Silverlight)中构建大型应用程序的人来说,长时间运行的流程并不是新闻.在HTML和JavaScript领域,问题和解决方案大致相同.

3. 后端的图层.你一直在看演示太久了.是的,大多数演示将所有内容转储到一台服务器上运行的项目中 我们假设您知道如何重构服务器以满足您的环境的扩展,性能和安全性要求.我们的演示主要涉及前端SPA开发.我们涉足服务边界,以显示数据如何通过服务API,通过ORM流向数据库.我们认为识别这些不同的层是足够的,并且为读者留下将这些层移动到不同层的相对微不足道的事情.我们有一天可能不得不重新访问这个假设.但有没有人认真地认为在服务器端层之间分配层/责任存在重大障碍？真？像什么？

4. 不引人注目的验证.当大多数人开始在HTML中使用"unobtrusive"这个词时,他们通常会指出将JavaScript保留在HTML之外.也许这就是你的意思,在这种情况下,SPA开发者无处不在......这就是为什么有许多"不显眼的验证"库可用.我想到了HTML 5验证,jQuery验证和Knockout验证.所有这些都在SPA开发人员的工具包中,并且没有一个"需要开发人员使用MVC部分视图和控制器".是什么让您觉得SPA需要任何服务器端资源才能使用无JavaScript的HTML标记实现验证？

5. Ids为安全风险.真？这是假的.关键值不再是任何其他数据值的安全风险.数百万个应用程序 - 不仅仅是SPA - 在URL和正文中向客户端传达密钥值.它是REST API的标准.它是ODATA的标准配置.你想通过说它们" 针对安全要求和功能集很少的区域 "来解雇它们吗？祝你好运.我认为你必须做得比在一个相对模糊的组织的整个网站的链接上休息你的情况更好.