In 2010, I was working on moving web app of Dilixiri to a iPhone app. (Dilixiri is a Turkish-English and English-Turkish sentence translation app.) The problem was of that time, our small team does not know anything about handling data between different softwares. I knew some stuff about TCP/UDP because of my PyQt book‘s example. I first thought about making a TCP server on the server side and then since Dilixiri’s page is a Django based HTML page that simply uses a HTML POST to translate a sentence, I tried to do the same thing as web browser does.
For two major versions of Dilixiri (1.0-2.0), it worked pretty well. I was simulating what web browser does by using actually same headers that what a browser does while making a request. Another problem was parsing response(HTML file). I used some simple “split( )” functions to find the text that I am looking for. (Now I feel embarrassed about it, especially after learning about the side effects and regex.)
However in 2012, instead of making another big mistake, I made something right without knowing that it is the best practice for Dilixiri(partially). In 3.0, I changed how the app handles the translation by using JSON in the middle. But I was afraid of third party users who could easily use it on their software. I got to think about a solution to handle it.
My first attempt was, implementing using GET parameters based API. So in this case:
But if somebody discovers this url pattern, it can be used without permission. Despite my first attempt that is in engineering may referred as a very bad implementation, this time I thought about giving an API key like some of the famous web services do. But if I request a translation:
It is the same thing. This request can be listened in the network and be repeated again. (like Man-in-middle-attack) At the end, I implemented something like:
I hashed request and API key same time that for every request, I use a different hash number. By implementing this, still relay attacks can be done but a fully working API that makes translations as same as Dilixiri became impossible without knowing API key.
A big drawback is you can only use just a one API key. Another is relay attacks. For an API like Dilixiri, it is not a big deal but when you think about other services. It should be handled, both immunity from relay attacks and being able to serve more than one clients.
How to achieve this ? Nowadays, in Computer Club, we are working on OZU-EMS(Özyeğin University Event Management System) that allows clubs to send their club events to this system and system will share it on its mobile app, web page and etc. Also it also saves time in the university side. (A professor that is responsible for the club, and the social coordinator in the university accept or reject this event request by the club easily in a painless way.) We were looking for a way to make an API to serve these events for different clients that are outside of the server. Such as an Android app or a Kinect based Windows app(CreativeOzu(another club) is working for that.). After a small research, I found that my Dilixiri 3.0 approach was the correct one, but lot’s of clients and different API keys, there should be a public key and private key. I personally wanted to share these links for detailed explanation about implementing this solution:
There should be other methods such as implementing HTTPS based service or something else. But I think such kind of custom solutions are better, if you wanted to handle and understand by yourself.