One of the "Next Big Things" these days is the use an MVC framework for developing Web applications. There are a number of MVC frameworks out there including Backbone, Ember, and the rapidly growing Angular.
Ideally these MVC frameworks are great, hook things together and any changes to the model (data) and all the views are updated based on the controller code. If there is changes to the model, the data is automatically updated on the server. This is the ideal case.
However, it assumes one critical thing, you have the access rights to CRUD data on the server. This is an extremely dangerous assumption.
In our iPhora security model, we assume the opposite and you do not have access rights to any data on the server. We do not trust anything and any request. We assume that you are trying to hack and inject. Your authorization is checked during each request. We looked at using Angular since it is the hot stuff of the MVC world and everyone seems to be using it. We also looked briefly at Backbone. However, these required us to hack and patch the code to do what we wanted it do. As a result, it would be hard to maintain in the future when new versions of Angular or Backbone comes out.
Since we have been using Dojo for awhile, we looked at a couple of Dojo-based MVC frameworks including Dojorama and the Dojox/MVC. These two also assumes an ideal MVC approach which is not what we wanted. Also Dojox/MVC is heavy.
Most of the MVC frameworks works well for simple applications and even more complexity applications. But for our iPhora applications like iPhora Touch, within one session, the user access rights and roles will vary constantly depending of the state and application the user is accessing.
One thing that all these MVC frameworks lack is good documentation not on how to use it but documentation regarding the core architecture and functionality. You have to go through all the code and test and sometimes it is trial and error and assumptions. What a pain.
So we decided to create our own MVC framework using Dojo. The newer AMD approach for Dojo lends itself to the MVC approach. Dojo already has core methods to handle MVC including dojo.store, dojo.stateful, dijit.watch/unwatch, and dojo.store.observeable. Also, don't forget the powerful dojo.subscribe and dojo.publish. We used the Dojorama project as a guideline and starting point. This MVC project is a good demonstration of the power of Dojo.
So where are we? Our initial MVC architecture is completed and we have modified our development tools to handle the new MVC approach. But, we expect more changes to come as we test. The base core code is almost complete and will be ready for a test during the next couple of days. Our existing page-based JSON Restful services API will require some minor changes that are relatively easy to make. We are half way done in updating our existing iPhora Dojo/Bootstrap widgets to Dojo 1.10/Bootstrap 3.2 with MVC-based hooks. So stay tune for more updates.
Ideally these MVC frameworks are great, hook things together and any changes to the model (data) and all the views are updated based on the controller code. If there is changes to the model, the data is automatically updated on the server. This is the ideal case.
However, it assumes one critical thing, you have the access rights to CRUD data on the server. This is an extremely dangerous assumption.
In our iPhora security model, we assume the opposite and you do not have access rights to any data on the server. We do not trust anything and any request. We assume that you are trying to hack and inject. Your authorization is checked during each request. We looked at using Angular since it is the hot stuff of the MVC world and everyone seems to be using it. We also looked briefly at Backbone. However, these required us to hack and patch the code to do what we wanted it do. As a result, it would be hard to maintain in the future when new versions of Angular or Backbone comes out.
Since we have been using Dojo for awhile, we looked at a couple of Dojo-based MVC frameworks including Dojorama and the Dojox/MVC. These two also assumes an ideal MVC approach which is not what we wanted. Also Dojox/MVC is heavy.
Most of the MVC frameworks works well for simple applications and even more complexity applications. But for our iPhora applications like iPhora Touch, within one session, the user access rights and roles will vary constantly depending of the state and application the user is accessing.
One thing that all these MVC frameworks lack is good documentation not on how to use it but documentation regarding the core architecture and functionality. You have to go through all the code and test and sometimes it is trial and error and assumptions. What a pain.
So we decided to create our own MVC framework using Dojo. The newer AMD approach for Dojo lends itself to the MVC approach. Dojo already has core methods to handle MVC including dojo.store, dojo.stateful, dijit.watch/unwatch, and dojo.store.observeable. Also, don't forget the powerful dojo.subscribe and dojo.publish. We used the Dojorama project as a guideline and starting point. This MVC project is a good demonstration of the power of Dojo.
So where are we? Our initial MVC architecture is completed and we have modified our development tools to handle the new MVC approach. But, we expect more changes to come as we test. The base core code is almost complete and will be ready for a test during the next couple of days. Our existing page-based JSON Restful services API will require some minor changes that are relatively easy to make. We are half way done in updating our existing iPhora Dojo/Bootstrap widgets to Dojo 1.10/Bootstrap 3.2 with MVC-based hooks. So stay tune for more updates.
Comments
In any event, it is indeed crucial to not trust data from the client. Due to that, using the Domino REST API directly is a bad idea for this sort of thing (though it's perfect for an example, which is why it shows up in tutorials). What you really want to have is an API implemented on the server that does this sanity-checking regardless of the source - so all the validation, access control, etc. done on the server and then exposing a specific REST API.
It gets more complicated when you have to do the same validation twice in order to avoid having to round-trip everything all the time, but that's sort of the hassle of web development.