POH5 application development and databinding (knockout.js)

[peterfry]

I'm currently planning an application with the following layers:

HTML  (5) + Javascript controller + RESTful services probably via JAX-RS (implemented using JPA)

Prior to looking at Aerogear my reseach has been focused on using knockout.js or backbone.js or similar.

I've been increasingly drawn to knockout.js since it seems to provide a javascript equivalent of the databinding functionality available in JSF plus some of the facelet usecases look like they  are  catered for (fundamentally the templating usecases).

There is also a mapping plugin which greatly simplfies the mapping code between the model and viewmodel (i.e. it is a MVVM framework), easing the integration with JSON based REST services.

Then I looked at Aerogear and Forge. It looks like Forge via a metawidget plugin has the ability to generate POH5 apps accessing JSON services (implemented using JPA)  so CRUD apps should be relatively simple!

So my question is 'how does the Forge generated app do databinding'? Are the any plans to integrate a knockout.js or equivalent databinding layer?

One thing that knockout.js doesn't really talk about is security in POH5 applications (since its primary concern is databinding and templating).  Aerogear on the other hand mentions it on its splash page (which is encouraging!)

[jbalunas]

Hi Peter,

Thanks for the post, we're seeing a lot more of these types of requirements.

The Forge HTML5 scaffolding does not do direct data-binding in the way that knockout does, at least not yet.  At the moment it is simply using jquery to trigger the ajax calls to the server.  We absolutely want to add this type of functionality though, although security processing is first on our list.

Speaking of security for HTML5 applications, I'd be curious about your specific requirements here?  What type of security are you planning on using, and/or features?  It would help us greatly to get some feedback!

Thanks,

Jay

[peterfry]

Apologies if the following is vague (or repeats what you already know!) but its an attempt at describing the security requirements requested.

I tend to develop self service browser applications in the financial services industry.

This means that the security of any application is paramount. Authentication as a matter of course is two stage, the user is challanged for a username and password and then challenged for a piece of memorable data.

In the server side based application (which covers pretty much all of the existing well known frameworks from JSF through Grails to possibly even the Scala Play framework) that authentication results in a session (either a native Java Servlet session or some framework specific mechanism to manage the users access to the application). Usually the maintenance of that session is via cookies but can easily be maintained via URL rewriting.

RESTful webservices are meant to be stateless so as I understand it the only way to secure these services is either to require the client ( via some javascript code) to obtain a session key object and send it back to the server on every request or to break the REST requirement and allow the use of a cookie (or URL rewiriting) to establish a session to track the user with that session being shared by each and every participating pseudo RESTful web service.

My inclination currently is to do the latter via a servlet filter or a more native JAX-RS mechanism.

Other concerns are CSRF - The usecase for this from various discussions on the net suggests that the security restrictions of the JSON communication (same origin policy) mitigate against this and only require that the site hosting the web pages must also act as a proxy for the REST services if they are hosted on a different domain (not really a problem for a self service financial services app). Does this mean a equivalent of the s:token from Seam is no longer needed?

Generally I belong to the camp that pure JAAS is hard to fit into security requirements of a real world application and have had to implement bespoke role and user maintenance on numerous projects.

[abstractj]

Hi Peter, no worries and thanks for the feedback.

We have been working to push forward security from the client to server side, currently doing R&D around this topic. Some concerns to bear in mind with regards to financial services is about security on the server side too.

User/password challenge + memorable data is a good approach. I know that HTTPS encrypts data before sending it out over the Internet, but should be great to add server and client side encryption, because HTTPS just cares about the transport. Why? Because sensitive data like these on the server could be compromised.

You might be careful about session hijacking issues when you trust on cookies to keep session and URL rewrite can allow end-user alter the submitted URL (for further information http://resources.infosecinstitute.com/owasp-top-10-tools-and-tactics/).

About RESTEasy is possible to use interceptors(http://docs.jboss.org/resteasy/2.0.0.GA/userguide/html_single/#Interceptors) or CDI interceptors to check your protected requests, the both alternatives are good.

I trying to figure out the relation between CSRF and JSON, but if I get it, the same can happen with XML payloads. We will never have a 100% guarantee that any controls will provide full protection, but maybe use a unique identifier to attach user request with a specific action and recreated for every request and action would prevent some issues. I'm not a Seam specialist but I think that check the appropriate authentication token is a good idea.

In Aerogear we have been doing some progress on the client side and the server side on DeltaSpike (http://wiki.apache.org/incubator/DeltaSpikeProposal) there's nothing set in stone actually, we appreciate feedback and suggestions.

[peterfry]

I've been trying out the JEE 6 POH5 archetype in the latest milestone release of JBoss Tools. The implementation of the REST services is exceptionally clean and is a great advert for JEE 6 (the use of CDI to inject the EntityManager rather than using the legacy PersistenceManager annotation is nice to see).

The purpose of trying out the archetype was to look at converting the example to use knockout.js. This has been reasonably straightforward and once I clean it up I'll upload it to this thread.

But in the process of converting the example to knockout.js it's highlighted to me what another much touted javascript library has to offer, namely backbone.js . Even though knockout.js made the html page data binding more intuitive, pretty much all of the app.js code is still needed with the ugly use of $.ajax or $.getJSON calls. After doing a search for 'javascript client api JAX-RS I came across:

http://coenraets.org/blog/2011/12/backbone-js-wine-cellar-tutorial-part-1-getting-started/

And though I'm not so keen on the backbone.js View API the Model API cleanly abstracts the app.js code.

I may try and convert the example to backbone.js .

There is another project that tries to combine knockout.js with backbone.js but I'm not sure how much traction it has but it seems to take the best bits from both javascript libraries (i.e. the Model definition of backbone.js plus the bindings and autoupdate features of knockout.js)

http://kmalakoff.github.com/knockback/

Cheers,

Peter.

[kborchers]

Peter,

I would recommend taking a look at the new JBoss Developer Framework http://www.jboss.org/jdf and specifically the client side implementation of the TicketMonster example https://github.com/jboss-jdf/ticket-monster

I'm hoping to contribute some minor improvements to that example when I have some free time but for the most part, I would recommend checking out their use of Backbone.

[peterfry]

Seems to be just what I am after! Thanks for the links, backbone.js it is (but I still like databindings a la knockout.js!)

Is there any intention to enhance the "poh5 + JEE 6" archetype in JBoss Tools to generate a project that uses backbone.js?

Presumably the ultimate goal of this archetype is to allow user to either pick some database datables or JPA objects and generate different javascript and java files, and if you have existing JAX-RS services then I guess it would just generate the javascript stuff.

My take on backbone.js views and knockout.js views ..... backbone.js views are like JSP's and knockout.js views are like JSF.

Cheers,

Peter.

[peterfry]

After some discussions with colleagues at work I realized there is another authorization usecase that becomes important in POH5 + REST apps namely field level permissions.

In a server side application world the server would be responsible for extracting data submitted by the web page prior to submitting it to the database.

This meant there was implicit (and actual) control over what fields on an entity a user could update when they submitted a request over HTTP.

REST apps probably initially will only offer control over what CRUD permissions a authenticated party has at entity level.

Is there any consideration being given to this as part of Apache Deltaspike?

It presents a considerable burden on organizations to implement field level permissions for services so I do have one suggestion which is that the field level permissions could be dynamically extracted from the HTML page definition at runtime i.e. parse the HTML page and extract a list of fields which are READ or READWRITE. This assume the server has access to the page definition (not always the case) and that the HTML page is in a parseable form (the backbone.js style templates aren't really, the knockout.js style ones more so although I still think it would be tricky).

[abstractj]

Hi Peter,

Shane started the discussions about the authorization API and object level permissions over here (http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/DISCUSS-DELTASPIKE-79-Authorization-API-td4566205.html)

Some organizations write APIs like this https://www.owasp.org/index.php/Category:OWASP_Java_Project to field validation, just keep in mind the several trade-offs when you start with field validation on the server side, like decrease your performance. In the most cases, the combination of right validation on the client side and some changes on the server side are the way to go.