sabato 21 febbraio 2015

My first time with Angular.js


I have started learning Angular.JS from scratch and here my first impressions:
  • Very coll (impressive!)
  • A real way to easy down the UI interface (my nightmare!)
  • It seems simple... too simple...
  • Yes, but wait... remember... nothing more than the presentation layer.
I was worried by a couple of things:

  • how to use security in Angular JS;
  • how to localize the strings that have to be set during js runtime.
I am going to explain how I solved these two worries in my next posts.


My first "test projects" for practicing on Angular.JS were focused on:

  • simplest ng-module in order to receive info via json and render them to the page;
  • simplest form bidirectional (coming / going to db);
  • UI grid;
  • Google Map (have to try!!);
  • put everything in DotNetNuke!
I found this link particularly helpful:
angular-ui.github.io


I found a quite easy way to solve the second problem (I am going to write something about that in another post).

The first problem was solved pretty soon:
the problem simply... does not arise.

I am going to explain a bit deeper this concept.

Usually security has to address one main goal: allow to access data/services only if the user has the right authorization.
There is a second, less important goal: adapt the presentation layer to the gained authorization.

Example: if I do not have the the authorization to change the info in a form, the "save button" should be absent on the page!

IMHO this is the real difference between standard "server-side-generated" page (php, asp.net,....) and "client-side-generated" page (Angular.JS,...); this difference can be summarized in this question:

"Who is going to decide if the button should or should not be shown?"

The first solution solve the complete security logic server side, sending to the client only the strictly necessary functions (if not authorized, the server will not even send the the button to the page), while the second solution delegates part (even significant one) of the security logic to client side.

This means that, Angular.JS (as every client side technology) can not solve the security issue itself: all the security logic has to be addressed by separate APIs entitle to check every service exchange among client web page and server web app.

But,even if I put in place this logic (server or client side) I should not forget to put in place the main security check: verify that the operation put in place is allowed!

Conclusion:

Working with client side logic helps a lot to focus on security issue leading to the correct sw architecture, and avoiding to mix up the main security goal with the secondary one.





Nessun commento: