微风js - 如何验证复杂的业务规则保存？ [英] Breeze js - How to validate complex business rules on save?

问题描述

我熟悉Breeze，因为我认为它可以帮助我很多处理数据。 Hovewer我最担心的是服务器端的数据验证。我阅读了文档，我知道你应该使用自己的ContextProvider并在其中应用自定义验证。我还阅读了有人在问的这个SO帖子类似的问题。

但是我觉得我得到了在BeforeSaveEntity函数中无法处理的情况。如果可以，请告诉我如何：

让我们说用户正在尝试更新一篇文章（他自己的文章）。本文有一些ID。
如何检查用户是否正在更新他的文章而不是某人elses（他可以在浏览器中更改文章ID，此ID可能是某人elses文章ID）。所以实体仍然是有效的，但是业务规则不允许改变所有人的其他用户的文章。

我想使用EntityFramework和ASP.NET Web Api

如果只有我可以得到像当前用户和BeforeSaveEntity函数内的文章ID ...

解决方案

您正确地关心客户端保存请求的彻底验证，也正确地不信任客户端发送的任何信息。

这里有两个问题：谁是用户，他/他真的拥有这篇文章。

谁是用户？

微风保持在认证业务之外，我们认为应该通过（在很大程度上是在您在服务器和客户端上编写的应用程序代码）外部的方式来解决。

我不会滚动我自己的安全层。这是麻烦的问题。您可以通过开始研究关于Web API安全性的Mike Wasson的文章。

一旦你知道用户是谁，你必须获得应用程序特定的事实关于他或她，例如userId和用户被允许做什么。

这是谁的文章？

我们假设当前userId是12345，更新请求指定了articleId == 42和userId == 12345的文章。显然，本文属于当前用户。那还够好吗我们应该继续保存改变的文章吗？

答案取决于你如何评估流氓客户端更新另一个人的文章的后果。我不担心更新一个Todo（也许我应该？）。我不会相信这个请求，如果它涉及一个银行退出。

我建议旋转一个单独的 DbContext 和查询数据库的articleId 42。

不要使用 DbContext 从 BeforeSave 中的微风 ContextProvider 。 DbContext 保存客户端修改的文章。您需要一个单独的 DbContext 来保存数据库中的实际实体，就像现在那样。这些是单独的实体对象在不同的​​状态。您不能在同一个 DbContext 中具有相同ID的两个不同的文章。

如果查询的文章具有userId 12345，则您知道客户端提出了有效的请求，然后继续。如果查询的文章的userId属性不是12345，则拒绝该请求。

您可以将此失败的请求视为潜在攻击，并将其记录在您记录安全攻击的位置。也许你会监控这个用户和IP地址，谁知道什么。我在这里没有深度。

我可能会用一个神秘的500拒绝这个请求。一个真正的客户端不会提出这样的请求，不想告诉潜在的攻击者我拒绝的原因。

I'm getting familiar with Breeze because I think that it can help me a lot dealing with data. Hovewer my biggest concern is data validation on server side. I read the documentation and I know that you should use your own ContextProvider and apply custom validation inside. I also read this SO post where someone was asking similar question.

But I think I got the case that cannot be handled in BeforeSaveEntity function. If it can, please tell me how:

Let's say that user is trying to update an article (his own article). This article has some ID. How could I check if user is updating his article and not someone elses (he could change article ID in the browser, and this ID could be someone elses article ID). So entity would be still valid, but business rule does not allow to change other users articles by everyone.

I want to use EntityFramework and ASP.NET Web Api by the way.

If only i could get to something like "current user" and ID of article inside BeforeSaveEntity function...

解决方案

You are rightly concerned to validate client save requests thoroughly and right also to distrust-in-principle anything the client sends.

Two issues here: who is the user and does s/he really own this article.

Who is the user?

Breeze stays out of the authentication business which we believe should be addressed by means that are (largely) external to the application code you write on server and client.

I would not roll my own security layer. That's asking for trouble. You might start your research with this article by Mike Wasson on Web API security.

Once you know who the user is, you must get application-specific facts about him or her such as the userId and what the user is allowed to do. I don't know where you get those facts as that is something specific to your application.

Whose article is this?

Let's suppose the current userId is 12345 and the update request specifies an article with articleId == 42 and userId == 12345. Clearly this article belongs to the current user. Is that good enough? Should we go ahead and save the changed article?

The answer depends upon how you assess the consequences of a rogue client updating another person's article. I'm not worried about updating a Todo (maybe I should?). I wouldn't trust this request if it concerned a bank withdraw.

I recommend spinning up a separate DbContext and querying the database for articleId 42.

Do not query the database with the DbContext from the Breeze ContextProvider inside the BeforeSave. That DbContext holds the modified article from the client. You want a separate DbContext to hold the actual entity per the database as it stands right now. These are separate entity objects in separate states. You can't have two different articles with the same id in the same DbContext.

If the queried article has userId 12345, you know the client made a valid request and you proceed. If the queried article's userId property is other than 12345, you reject the request.

You might treat this failed request as a potential attack and log it where you log security attacks. Maybe you'll monitor this user and the IP address and who knows what. I'm out of my depth here.

I'd probably reject the request with a mysterious 500. A real client wouldn't have made such a request and I don't want to tell a potential attacker the reason I rejected it.

这篇关于微风js - 如何验证复杂的业务规则保存？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！