My Contributions to Tracker - GSoC 2016

The tracker project is one of most interesting projects that I have come across as a computer science undergraduate. Therefore to get myself familiar with Tracker and SCoRe, I studied about projects such as Tracker, OpenDF, and OpenADS. I started getting myself involved with SCoRe by analyzing the code base and eventually fixing reported issues in Github.

This post describes the tasks I have done so far in the context of tracker.

The following tasks were done before the project proposal was submitted

1. I started the NodeJs server and played with the existing User Interfaces (UIs). No any issues were faced when setting up the system and getting it up and running. I tested the provided endpoints with dummy data to create trackers and add tracker location data. Here is a screenshot I got when the path analyze option is carried out for a tracker I created which has data about 4 locations (timestamps) on the map.

2. I inspected the code and tested the endpoints with dummy requests. While doing this, I found some issues in the endpoints. I have reported them to corresponding mentors and to the Google group of SCoRe Lab. I will list some examples here briefly.


For example, POST /api/tracker/create takes three params id, status and device and saves them in the mongo database. But When I check the mongo db using robomongo, the id is replaced by the auto generated id of mongo. The reason for this as I found is that the model defined using mongoose schema does not have a field to store the Id sent.
Another example is that the current implementation can be manipulated to enter multiples entries with the same mac. I believe that the mac better be unique and that it should be enforced by the corresponding route itself.


More details about the two issues mentioned can be found in my community post


3. The current implementation does not have a proper authorization and authentication methodology as reported in github issue#2 I have forked a local copy of the Tracker repository and implemented codes to address this issue and sent a Pull Request (#37). This is what I have done so far.


Create a new user in the system with the attributes Name, Username and Password when a post request is sent to the corresponding endpoint. Password is hashed using bcrypt.
A sessionless mechanism which generates a web token using JSON Web Tokens when a user tries to authenticate using valid credentials and sends back as a response. This token would be sent along with future requests to validate them. The middleware to check requests is not yet enabled. Invalid or incomplete requests are properly handled.
Passport authentication using a local strategy for the use by the web interface which maintains a session expiring in a given time. Middleware to validate requests is also implemented.
A user interface for the signup and signin task which consumes the above endpoints. 
In addition, I have created a wikipage in the repository to show details about the service endpoints related to resource model