SPA架构问题

时间:2013-04-21 15:01:06

标签: security memory-management knockout.js breeze single-page-application

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

  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. 在网址中公开基于主整数的密钥。
    这在OWASP中是不可取的。 因此,SPA应用程序"似乎"定位具有很少安全要求和小功能集的区域。你觉得怎么样?
  6. 感谢。

2 个答案:

答案 0 :(得分:18)

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

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

关于你事实上真正关心的可能性,我提供了一些快速的反应,特别是因为它们与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. ID作为安全风险。真?这是假的。关键值不再是任何其他数据值的安全风险。数百万个应用程序 - 不仅仅是SPA - 在URL和正文中向客户端传达密钥值。它是REST API的标准。它是ODATA的标准配置。并且你想通过说“目标区域具有很少的安全要求和小功能集”来解雇它们?祝你好运。我认为你必须做得比在一个相对模糊的组织的整个网站的链接上休息你的情况更好。

答案 1 :(得分:2)

我已经构建了一些SPA应用程序,范围从小到大(超过100个脚本和视图)。只有极少数人能够向公众开放。其余的都经过严格的访问结构。从服务器返回未授权的401并且客户端只是处理401以将其重定向到登录屏幕非常简单。沃德先生和帕帕先生说得对。退出演示模式并尝试找到您遇到的问题的解决方案。我已经看过John Papa的SPAs,在Breeze上看了很多文章和应用程序,我必须告诉你,我的应用程序都没有使用Breeze从客户端做查询,因为你不需要!!

此外,我只是扩展了我所学到的知识,并提出了解决问题的方法。这不是您的查询的答案,但我只能提供简短的评论。没有技术是完美的,没有一种方法可以做任何事情。我的服务器端被锁定在需要锁定的位置,我在客户端的路由被锁定(如果使用durandal看看guardRoute),我的脚本被缩小并且我的图像是sprited(如果有一个像那)。总而言之,SPA是一项很棒的技术,你必须找到解决问题的方法!