Internship in Australia (Chapter 9— Digging Hexoskin)

I am really getting tired of Hexoskin.

The device is great. I let one of my friend test it when we played badminton last week. (I can’t wear it myself because the size I was given is XXL, while I actually can even fit myself comfortably in S.) I can’t say if the data is accurate or not because I don’t have any other sources to compare. It works as it is described to be, at least, and I now have an example set of data synced into my account. I got the API developer key from Hexoskin team, and have read enough of OAuth2.0 to know basically what I need to do to start using the API. The process of actually implementing it should be straightforward…until it doesn’t.

I wrote some quick code to implement the process of obtaining the authorization token to access Hexoskin’s API. Basically this requires me to redirect the user of the web application to a specific URL, which is generated in accordance to Hexoskin’s format and composed of details such as my client ID, the authorization grant type that I want, the scope of access I want, and the URL I want to redirect to after the user authenticated my request. Using Flask and Ruth, which is a python library for managing OAuth services, I can finish the code up fairly quickly. When I tested it, however, I can fill in the username and password of my account to login with Hexoskin, but then the error occured which said there is a problem verifying the app (my developer client).

Looking around the API document, I found out that the problem occured because the URL I want to redirect to is not registered into my client’s data. Hexoskin will only accept the URL registered into [redirect_uris] field of the client’s data. I can find from the email they sent me about my client where to locate this information, but they provides no instruction as to how to edit it. I looked around the API document again. (I can’t say the document is well structured. It is informative enough, but it is easy to skip pass what you are looking for in those walls of text.) I spotted a paragraph that says I can send a PATCH request to update my client. I sent it using the curl command in terminal, but the response is an error ‘unauthorized’. (Which I kind of expected, since it would be extremely stupid to allow anyone with a correct URL to edit my client.)

Finally, I gave up and sent an email to Hexoskin asking for an advice regarding the issue. They replied in the night of that day (I guess it’s Canada’s day time) highlighting the solution in their API document about obtaining the authorization just for editing the client data. It is even in the page I have already looked up many times, but somehow I never spot that piece of information. I felt like a moron.

So I sent the PATCH request again, this time with an authorization token obtained, and it finally is updated. I then try to authenticate my app with my Hexoskin account again, this time there is no error and the page redirects as it should be. However, Safari can’t open the page I told it to redirect to because it can’t establish a secure connection to my page.

I quickly guessed that it has something to do with the HTTPS. Apps with Flask are created to run with HTTP, but when I was updating the client for Hexoskin I found out it would not let me use HTTP URLs to redirect and I need to use HTTPS. I don’t know much about these, but I guess a webpage address can’t just be accessed using HTTPS without having to do something with it first to enable this. Reading around quickly (I don’t really have much time, even though I would love to learn new things.) I found that, roughly, I need a certificate to allow HTTPS access. Normally and in real world applications, we can register for one with a fee (and some security measures implementation), but that would not be good idea for this yet as I am running on localhost. I did some extensive search until I found this link that can ‘fake’ certificate to run HTTPS on localhost using little tool called ‘stunnel’. This means now my app would need to be accessed using the port 8443 instead of 5000 though, since stunnel will be the one connecting to port 5000 for us and make it ‘secure’ so that HTTPS can be used. (I think actually it does nothing, it just let us experiment first without a real certificate.) Therefore, I need to edit my client again to add the redirect URLs with port 8443.

With that done, it should have worked as intended. I was already getting tired of it. This simple task of implementing the OAuth 2.0 process should not have take this long, it was causing a strain on my other works and delaying progress more than it should.

That proved not to be the case. After the process of authorization, I wrote a script for the page that Hexoskin will redirect me to so it can get the code provided within the URL and initiate a token exchange procedure to create a session and then redirect to the welcome page, which will show some information of the user accessed through Hexoskin’s API. However, even though I can get to the Hexoskin’s login page, fill out the username and password, grant the correct access and get redirected to where I should go, that page refused to load. Safari said the server unexpectedly drop the connection, maybe because it is too busy. My own MacBook is the server though, and it is nowhere near busy enough since I am the only one trying to access the damn thing. This is absolutely nonsense and I need to figure out the real cause of this error myself.

A weekend passed, and I came back to look at it with a fresh pair of eyes. I tried using a different browser at first, because sometimes Safari might be the cause of some abnormal behaviours. Firefox yielded just about the same error though, so it has something to do with the app itself. I tested the session created and found that it is already working. I can access the data now, but when I try to redirect to the welcome page I get the error.

Suddenly I noticed that in the URL bar, the address for welcome page did not started with HTTPS. I immediately suspected this, since by using stunnel the base address to access my app has been changed from localhost at port 5000 (Flask’s default) to port 8443. However, since I generated the URL for redirecting with the Flask’s function url_for and not by hard-coding, maybe it generated HTTP URL instead but still use specify port 8443 to connect. That would certainly cause an error since port 8443 was not configured to accept that.

So I looked up on how to force Flask into using HTTPS when I call the url_for function. Luckily, the problem has been encountered by other developers too (obviously) so someone has already asked on Stack Overflow here. I changed the wsgi.url_scheme to'https' and that is it. The URL generated using the function is now using HTTPS.

I fired up the app again (for about the 100th time), and follow along the steps to authenticate my app and access the Hexoskin data again. This time, everything worked as it should be, but then a python error occured. It said that I was trying to access a non-existing attribute of an object g. It is a global object from Flask that you can store some data in. I used it to create an attribute to store the session created after exchanging the authorization token, so that it can be used when I want to call Hexoskin API. Luckily this time it can easily be solved. A quick lookup on the internet confirmed my suspicion that this object is destroyed and a new one is created everytimes a redirect occured.

Therefore, I stored the session somewhere else instead. Finally, the welcome page can be loaded normally, and the account’s information can be pulled and displayed. A long journey, but I finally get the first steps done.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.