All in a ‘View’

It’s over a week in now, and although slightly better off than where I first started, I’m still rather lost.

Read lots and added more things into the reading/tutorial list to go through:

  • Stumbled on a question on Unobstrusive JavaScript vs JavaScript Application link on Reddit.
  • Unfamiliarity to Node.js led to: How do I get initiated? (I agree with the asker that the documentation on node.js is absolutely unfriendly for beginners)
  • Angular has a pretty steep learning curve, so I had to look for other guides.
  • If I find the time, perhaps try to draw similarities and parallels from Angular to Ember.js, which hopefully will aid the understanding of Angular better in terms of the client-end MVC.

Sat through a really long one today with Jon as he was revising the module of saving Polls to the MongoDB database. We covered everything from creating Services/Factories in Angular to figuring out the $resource feature in the API. The day was spent reading through documentation and loads of fact finding which I also intend to catch up on through the git commit logs of the code (time I’m trying to make – perhaps burn a bit of midnight oil over the weekends to get this done).

Perhaps let’s start with some of the interesting and useful content I’ve learnt about today (which may be obvious to adept developers out there).

Client side and Server side validation

I think the best way for me to explain this is to refer to the best answer itself:

Client-side validation just avoids the client from going “but I filled this all in and it didn’t tell me anything!”. It’s not actually mandatory… Server-side validation is also crucial due to the fact that client-side validation can be completely bypassed by turning off JavaScript. In a way, JS-driven validation is a convenience and an aesthetic/cosmetic improvement and should not be relied upon.

We decided to add a client-side validation to our poll creation because we felt that it would be better to use Bootstrap elements to handle the user experience of invalid inputs. However what was more important was still the fact that server-side validation is necessary as highlighted in the above quote. Without a proper way to inform the user that the invalid response is made, the user (a non-tech initiated person) may not know if the poll is created for real.

With this security and usability feature in mind, it led me to know more about a very important web application development concept of…

Securing the API

Part of securing the API involves the server-side validation as covered above. The purpose to this is because we want to prevent database manipulation by a user because of an insecure PUT request. For instance, in other applications such as one that keeps score, we do not want the user to be able to save invalid strings of information that may trigger unwanted changes to the database. This includes changing the user’s score to another score value found in the database (or simply edit it due to lax permissions).

In our case, it was important that we validate the Poll model API such that we disallow simple exploits to the database, returning us invalid strings of information when we retrieve the poll from the database.

One would also want to secure the API also because anybody who can view the page can also view each javascript file that is included in the HTML file on the page itself. That means the user would know exactly how it is implemented in some way on the front-end for the validation. This is also why Client-side validation is certainly not good enough.

Use of REST Clients to test the API

Chrome Webstore has a good app for this purpose. REST Clients are amazing because they handle all the different requests: GET, POST, PUT, and many of the other usual CRUD and non-CRUD types of HTTP requests to the server. Our poll creation module for instance started in the beginning as a PUT request that deals with the following lines of code:

Poll.findOneAndUpdate({
"_id": req.params.id,
"owner_id": req.user._id
},
{
$set: set
}, ... 

Using a REST Client allows us to check if the request was valid and successful with a Status code 200 response (which could also be observed from the Inspector in Chrome.), and also to see if we can manipulate the data in the PUT request. In an earlier version of the code we simply used the entire req.body to the PUT request, allowing users to do things they should not be able to, which brings me to the next learning point.

Principle of Least Privileges (from Wikipedia)

The principle means giving a user account only those privileges which are essential to that user’s work.The principle applies also to a personal computer user who usually does work in a normal user account, and opens a privileged, password protected account (that is, a superuser) only when the situation absolutely demands it.

This idea also carries forward to user creation in our servers and also to ensure that we create users that have privileges for the whole ‘you-have-only-one-job’ principle. For example, when creating a user with  privileges to a folder under public_html/www, that user should only be given to the rights of www (if he/she is the web designer) to create posts or do whatever he/she wants within the contraints of that folder.

Mission Control: Twitter Bootstrap

Professor Min-yen did a Mission Control today on Bootstrap which I sat through via Hangouts on Air whilst working on the project with Jon. Funnily enough, almost all the features that we’ve been playing around in our View layers are all bootstrap UI objects. Revisiting the basics was also refreshing as we see some Sublime Text action from the screen. Got to appreciate GruntJS a lot more after watching the painful save-and-refresh process that was broadcasted.

Wrapping up

Still tons to do with regards to the project. Shall find a day to meet up and bulldoze through development as far as possible. Glad there were a handful of takeaway points from today.