SproutCore 安全和身份验证问题

发布于 2024-10-13 17:02:16 字数 503 浏览 5 评论 0原文

我一直在尝试学习一些关于 SproutCore 的知识,遵循“Todos”教程,我有一些网上找不到的问题。

  1. SproutCore 应该将所有业务逻辑转移到客户端。这怎么能不缺乏安全感呢?恶意用户可以轻松篡改代码(因为代码全部位于客户端)并更改应用程序的行为方式。我这里怎么错了?
  2. SproutCore 使用“DataStores”,其中一些可以是远程的。如何避免恶意用户不自行与后端交互?使用某种 API 密钥是行不通的,因为代码位于客户端。这里有某种约定吗?有什么想法吗?这真让我烦恼。

提前致谢!

PS:有人认为卡布奇诺是更好的选择吗?我决定使用 SproutCore,因为有关 Cappuccino 的文档看起来相当糟糕,尽管 SproutCore 的文档并没有变得更好。

I've been trying to learn a little about SproutCore, following the "Todos" tutorial, and I have a couple of questions that haven't been able to find online.

  1. SproutCore is supposed to move all of the business logic to the client. How is that not insecure? A malicious user could easily tamper with the code (since it's all on the client) and change the way the app behaves. How am I wrong here?
  2. SproutCore uses "DataStores", and some of them can be remote. How can I avoid that a malicious user does not interact with the backend on his own? Using some sort of API key wouldn't work since the code is on the client side. Is there some sort of convention here? Any ideas? This really bugs me.

Thanks in advance!

PS: Anyone thinks Cappuccino is a better alternative? I decided to go with SproutCore because the documentation on Cappuccino seemed pretty bad, although SproutCore's doesn't get any better.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

£烟消云散 2024-10-20 17:02:16

伊恩,

你的担忧是有道理的。问题是,它们适用于所有客户端代码,无论什么框架。所以:

Web 应用程序是复杂的事情。将处理转移到客户端是一件好事,因为它可以加快应用程序的响应速度。但是,服务器必须验证所有数据输入,就像在任何其他 Web 应用程序中一样。

此外,所有 Web 应用程序都应使用系统安全中流行的众所周知的身份验证/授权范例。身份验证意味着您必须验证用户是否是他们所说的人,并且他们可以使用系统,而授权意味着服务器必须验证用户是否可以执行他们正在尝试的操作,例如他们是否可以创建新的数据条目或编辑现有的。不向用户提供不允许他们执行的 UI 选项是一个很好的设计,但您不应该依赖于此。

所有 Web 应用程序都必须执行这些操作。

关于“与后端交互”的问题:同样,所有 Web 应用程序都有这个问题。您可以打开 firebug/webkit,查看 RIA 在其操作中使用的所有 xhr 请求,并模仿它们尝试在该系统上执行某些操作。同样,这个问题是通过您必须实施的身份验证/授权检查来解决的。任何人都可以使用任何 Web 客户端向服务器发送请求。由开发人员来验证该请求。

SproutCore 中的数据源只是 SC 应用程序与服务器交互方式的抽象。然而,归根结底,SC 所做的只是向服务器发出 XHR 请求,就像任何其他 RIA 一样。

Ian

your concerns are valid. The thing is, they apply to all client side code, no matter what framework. So:

Web applications are complicated things. Moving processing to the client is a good thing, because it speeds up the responsiveness of the application. However, it is imperative that the server validate all data inputs, just like in any other web application.

Additionally, all web applications should use the well known authentication/authorization paradigms that are prevalent in system security. Authentication means you must verify that the user is who they say they are, and they can use the system, with Authorization means that the server must verify that the user can do what they are trying e.g. can they create a new data entry, or edit an existing one. It is good design to not present users with UI options that they are not allowed to perform, but you should not rely on that.

All web applications must do those things.

With respect to the 'interacting with the back end' concern: Again, all web applications have this concern. You can open up firebug/webkit, and look at all the the xhr requests that RIAs use in their operations, and mimic them to try to do something on that system. Again, this concern is dealt with by the authentication/authorization checks that you must implement. Anybody can use any webclient to send a request to the server. It is up to the developer to validate that request.

The DataSources in SproutCore are just an abstraction around how SC apps interact with the server. At the end of the day, however, all SC is doing is making XHR requests to the server, like any other RIA.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文