0

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...

Community
  • 1
  • 1
Tomasz Sikora
  • 1,649
  • 3
  • 19
  • 30

1 Answers1

1

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.

Community
  • 1
  • 1
Ward
  • 17,793
  • 4
  • 37
  • 53
  • Thank you very much for your response. It helped alot. – Tomasz Sikora Sep 18 '14 at 06:41
  • "You can't have two different articles with the same id in the same DbContext" is good advice - normally queries which do not bring entities back from the database avoid this problem (e.g. context.Mytable.Any(a=>a==3)), but not so with Breeze – Brent Apr 15 '16 at 05:37