ASP.NET Web API knockout validation

Question

I have a question related with client validation using knockout and ASP.NET Web API. I want the views will be completely static (may be excluding root index.html/cshtml) and I don't want to repeat myself by writing data annotations attributes rules in js by hands.

My context is a mid-size (~20-40 entities with biz layer) app on Durandal.

Unsuccessful/unappropriate ways I found and their explanation:

1. Use Breeze.js

At first view, Breeze.js looks like exactly what I need. How it works: it shares json via /Metadata link, then it maps one to knockout.valudate plugin. Everything is fine, but sharing the entities looks weird for me (I need to forget about Nunit, complex server logic and so on...And it is just scary to make your datacontext public: insecure and not data-safe!). Saving method with JObject argument also looks strange for me.

2. Get data from web api, metadata from either Breeze or Web Api (how?) and transform it on client

The only solution I find close to this it is this one: https://github.com/johnculviner/FluentKnockoutHelpers . It renders ALL(it is not so crucial, but is not good from my point of view) metadata it in cshtml, then he maps it for knockout.validate. May be there it a similar ready to use framework with similar functionality where I can get matadata from api via json and provide in knockout?

3. Render cshtml in html on build

Complex build process!

May be you have another solutions for static HTML and Web API applications?

Jaunita

Re: Breeze - I don't quite understand why making a datacontext public is insecure and not safe - if you have a Web API action that can be hit without security, then that isn't a Breeze problem - that is your problem for having an unsecured API. The reason to use a library like Breeze is to decouple your client side code from your server side code. I don't know of any reason to take server side logic out just to use Breeze.js. – Babbette

Thx PW Kad, may be just I didn't understood the reason of the breeze. I just seemed hello world examples at their site, john papa pluralsight hello world training. If I understood right, breeze is dedicated for non-complex helloworld apps with no real context? Did you used it in real apps? – Jaunita

PW Kad, Could you get your opinion about this example: src: github.com/johnpapa/PluralsightSpaJumpStartFinal , demo: papademo.azurewebsites.net . It uses breeze for saving some data. Do you think that is good example of breeze usage? From my point of view, it is just hello world and nobody need to save data using breeze cause it is not safe. – Jaunita

Answer 1

For starters, we have to be in agreement about one thing first -

Getting Data from the server using Breeze can be tricky to set-up the first time if you aren't experienced in JavaScript

Let's either look a few reasons why and examples on how to overcome that challenge, or skip over the non-required reading and talk about security when using Breeze.js or any client-side application -

<!--
    If you think this next section is 'Too Long' : 'Don't Read'
        and are just interested in security, skip down until
        you see 'Why is Breeze.js secure?'
-->

<section role="TL:DR">

The docs on breeze.js are always updating and improving but as a community we could improve to learn more about how to leverage breeze.js. Here's a few ways to hints and some basic scenarios of how to set up breeze.js in your client-side application -

Basic scenarios

1. Getting data from a Web API Controller Action -

   You can set Breeze.js up to use it's own metadata when consuming a Web API route -

   http://www.breezejs.com/documentation/web-api-routing http://pluralsight.com/training/Courses/TableOfContents/building-single-page-applications-breeze

2. Getting data from a Web API Controller Action with EF / Breeze.WebApi

   You can set Breeze.js up to use ASP.NET MVC 5 / Web API 2 Projects in VS2012/13. If you want to see how to utilize the server-side Breeze.WebApi as a helper check the links within this list or on online education sites like PluralSite.com -

   http://www.breezejs.com/samples

   http://www.pluralsite.com

   In the samples you will find how to use a good 85% of currently used web technologies. This includes Angular, Durandal, MongoDb, Node, Entity Framework, Require, Knockout, Ruby, Twitter Bootstrap, Backbone, etc..., etc...

3. Learning how Breeze works -

   http://learn.breezejs.com/

4. Hitting a server from your SPA that is completely decoupled -

   Why spend all the time setting up your own client-side data library and creating object graphs or using mapping libraries that aren't lighting fast? JavaScript ORM's are quickly becoming all the rage because why keep rebuilding the wheel? How can Breeze do it?

   http://www.breezejs.com/samples/edmunds

   http://www.breezejs.com/samples/espn

   Two great examples where completely decoupled API's can be consumed by client-side technology without tying the client-side stuff to any certain stack on the server-side.

Why is Breeze.js secure?

You should never expose any data to the outside world regardless of what it is or how it is generated. If you have an application on the client-side or the server-side that isn't properly authenticating it's users before returning data than how can you ensure you were properly authenticating before looking at client-side technologies?

What about when posting data back with saveChanges()?

There are very few situations in which I would design an app that gave a browser free roam to post / update my database. One might be if the content being changed was in very early development cycles where I was testing getting and posting data, and the business layer and what it allowed (probably verified through unit testing) was set up to allow unrestricted read/write of the data.

But what about moving a browser-based application to production?

I would never put my signature on a document that I didn't read over and was / am 100% sure that the document was ready to be signed. I would also never pass code from a dev or QA environment into a production environment without ensuring that my requirements were being met given the technology stack I am using. If using ASP.NET MVC and Session to store user information is the direction your application should take, then decorate your controller actions with the [Authorize] attribute. If you have another form of security then you need to always maintain proper security levels of the data you are exposing.

Never trust a browser-based application to provide you non-malicious content, even 99.99% of the time - the .01% could be the straw that broke the camel's back.

Babbette