What I’ll do this week (February 26)

There are a lot of things that I’d like to do, I’ll enumerate them in order of importance.

  • Search pools and users, that implies that I need to create a way to query a regular expresion or at least the begining of one of their string properties. I also need to filter the pools by its `public` property.
  • Pool owners need to split the bill, they should be given the options of spliting it evenly or with custom amounts (do we need to make sure that the total of all the custom amounts sum up to the total of the bill?).
  • Pool needs to specify who you should pay to, how much money do they owe or who payed more than necessary.
  • The only payment method available right now is cash, the pool owner should be the only one able to change the pool and relation to the pool properties.
  • Maybe invites should be visible through an interface in the app, I think that the best way to approach this is to create a new relation between the pool node and user node that indicates that he’s been invited. Because otherwise there is no other way to find out who you have invited, the email is send and after that it all depends on the user clicking the link.
  • We need a Facebook and Google login (I think this will be done by someone else).
  • User profile images are not critical (because we have default profile gravatars) but would be nice to have, we should store them somewhere outside the database, maybe store the path to the file in the node, or use an external service like Amazon S3.

What I did this week (February 19)

This week I advanced a lot in the relation api for neo4j, altough I’d like to improve it, we can get along with it for whole project. Also, in the Cooper api, we can now create, join pools, users can invite other users and invitation links are sent to them via email. Marco and Poncho managed to have a beta version of the Android app, most of the api functionality is already implemented in the app. It’s been a productive week.

What I’ll do this week (February 19)

This week I’ll work in creating relationships in both relationships, relations that go from a to b and from b to a at the same time. This will be useful to find users that participate in a pool and the pools in which a user participates. I will also work in getting all the relationship entities in a single callback. I will end the pool model and its relationship with users.

And from the frontend, they say they will have the login, register (email, facebook and google), and the users and pools list views ready for the end of this week, in both the browser and android app.

Update: It seems like neo4j relations are expressed only in one direction, like (a)->(b) or (a)<-(b), however, they can be traversed in any direction with the same speed of traversal. Anyway, when querying for a relation that we don’t know or care about the direction (like the participates relationship between users and pools), we can ignore it just by don’t specifying the direction (i.e.: `MATCH (neo)-[:PARTNER]-(partner)`).

From: https://dzone.com/articles/modelling-data-neo4j

What I did this week (February 12)

So I accomplished what I promised in the last premortem post. We have Neo4j relationships working with properties that are contained in the edge, just that it only works in one direction, a relation of the form (a)–[relation {props}]–>(b). I want to be able to create relations in both directions, so that for example, we can get the pools that a user participates in but also I want to be able to get the users that participate in a pool. From that we need to be able to get these nodes from an endpoint in the api, and so I need to create methods to find the nodes in a relationship. That will be enough work for this week. As well as defining the complete pool endpoints and model.

This will be useful: https://neo4j.com/docs/developer-manual/current/cypher/clauses/match/#relationship-basics

Quantum Computing

Here’s a really good video that explains (vaguely) quantum computing.






The fact that quantum compures have much more computational power than modern computers and are capable of factorazing very large numbers is a big threat to today’s cryptgraphic algorithms that rely on the assumption that factorizing really large numbers is a a so expensive operation that is nearly impossible to do so, but quantum computers will be able to complete the factorization in a short enough amount of time, and when cryptigraphic algorithms collapses so does network security.

But sure enough, quantum computers are not just a threat to network security, they are too the solution. Quantum cryptography relies on the Heisenberg Unsertainty Principle, which states that an observer cannot fully measure a moving object’s position and path without affecting one or the other.

And here’s a TED video explaining The Heisenberg Unsertainty Principle:




Koley (CTO of Juniper Networks) explains: “Typically, photons are used over a fiber-optic channel to achieve this [transmit information in quantum state], any attempt to measure one of the entangled photons leads to changes in the quantum state of the other, and therefore is detected. Thus, QKD offers a key distribution mechanism where any attempt to intercept the key by eavesdropping is revealed and the keys are discarded. QKD is not vulnerable to cracking attempts by quantum computers the same way that traditional cryptographic techniques are because any interception attempts in the QKD paradigm are readily detected. This is one of the reasons QKD is considered to be a good candidate for post-quantum security.”

And here’s a video explaining the QKD algorithm:



More resources on the subject:





SQL Injection Attack

Sometimes web developers don’t realize that their SQL queries are able to circumvent access control and sometimes they allow access to host operating system level commands.

An SQL Injection is a method of creating or altering existing SQL commands to expose hidden data, override existing data or even delete it. This is usually accomplished by taking advantage of existing static parameters in appliction to build SQL queries

used to combine it with user input. This way, malicious users can paste extra SQL queries into the application, and, depending on the privileges given to the app’s user (usually admin privileges), they are able to perform different actions.

A worked example of the issues regarding SQL Injection

What is the solution? Just sanitize the user input. It’s basically validating that the user input is what you expect it to be, check that it’s an integer, check that it has certaing format, check that it does not contain weird characters or even sql sentences. Also, mutate the original user input to convert special character to its html equivalent, remove line breaks and extra space and strip octets.




What I’ll do this week (February 4)

This week I’ll translate what we had in the backend to use the new database. I think that should be my first priority. Then I’ll work in the implementation for the relations between the nodes. I’m a bit worried about the fact that I’m not testing the api for the database. Maybe later. Marco is now working on the frontend web application too. He defined the roles for everyone, since we are a big team.

What I did this week (January 29)

This week I did’t finish the helper functions for neo4j but I have enough functionality so that we can start working developing the basic models and endpoints for the api. Now we can create models, restrict uniqueness of some fields and index the nodes in the database for fast lookups. With this functionalty we can start managing the users, and the money pools, we still need to implement the relations. There is no news for the mobile application.