How I became enlightened - Aksesi as a proxy Skip to content →

How I became enlightened – Aksesi as a proxy

At the last Friday’s afternoon, when I was doing housework, I came up with an idea about Aksesi’s development direction. It just appeared in my mind. Before I started this project I had only known that it will be an application that will allow to authenticate a user with gestures usage. After some time, I decided to support also characters and then I realized that it would be nice to have back-end service that will perform all computations.

In this post, I’m describing my idea with the majority of adopted conventions. I want to mention that this idea will probably change many times.

I would like to remind you that all of the sources are available in my Github repository. Moreover, in the README file, you can find short project description with its main assumptions.

Gesture conversion

At the beginning, I should introduce you the idea behind making gestures readable for the computers. As you can read in the Handling user gestures post, all of them will be handled as lists of (x,y) pairs. One list will be representing one gesture. Having those gestures handled they will be converted into textual representations. There are many strategies for conversion. One of them assumes that it will be able to recognize a line depending on its angle of inclination. Another one may perform interpolation or pass gesture to a machine learning algorithm which will decide about textual representation. When a conversion output will be ready then the gesture will be replaced in the string:



In the next steps, passwords will be appropriately hashed and stored in a database as regular text.

The first concept

The very first concept was about creating front-end application written in JavaScript and back-end service in Java. Those two applications should communicate through HTTP. Front-end will be responsible for interacting with a user, back-end will process data. I assumed that there will be only one HTTP Request (1) with the password within the data and one response with information about authentication status (2).

This idea is easy to implement but not comfortable to adopt in an existing system. Moreover, depending on the chosen conversion strategy, it will probably cause efficiency issues on the back-end side.

Component-based solution

The second idea was to divide both applications into smaller parts and provide it as modules which will be ready to use. It was really nice idea because everything user has to do is to import one JavaScript file, add one dependency in the application which will create REST endpoint and that’s all. Despite making it easier to add into an existing system, there is still the probability of potential efficiency issues connected with the conversion unit.

Proxy idea

The idea, I came up mentioned Friday, was to use the Aksesi as a proxy. In this scenario, the authentication process is a little bit more complicated.

At the beginning client’s front-end application (with the Aksesi module installed) sends an authentication request (1) that contains the password:

Before going to the back-end service, the request is passed through the Aksesi Proxy where gestures are decoded and replaced with their textual representations.

Requests with decoded passwords (2) are then redirected to the back-end service which is responsible for comparing passwords. After determination whether the user should be logged, the response is sent, firstly to the Aksesi Proxy (3), and then it is returned to the client’s front-end application (4).

“Proxy idea” has a lot of pros. First of all, Aksesi is responsible only for gesture conversion and its logic doesn’t depend on any other application. Secondly, a user sends the authentication request to the Aksesi Proxy, and then the proxy sends the request to the back-end application. It means that user is not able to see a converted password. Another advantage of this solution is that the back-end application doesn’t know about the proxy so it doesn’t matter if application e.g. uses Single Sing On mechanism. The last thing which should be mentioned in this paragraph is ease of configuration. A user adds simple JavaScript module, performs basic configuration and it is ready to use. The Aksesi module will find login form, provide gesture area, handle password and, at the end, redirect all of the login requests into the proxy.

In this post, I showed you how an idea of Aksesi application evolved during a few weeks. As I mentioned at the beginning of this article, I don’t know if it is the final schema, but it is the best solution that I invented up till now.

I would like to remind you that all of the sources are available in my Github repository.