This week, I set Wt aside to focus more on the WooCommerce WordPress plugin and the POCO C++ libraries, as both will play an important role in the project.
WooCommerce REST API
An amazing thing about WooCommerce is their easy to use REST API. It is really useful for developers that needs to extract important data in JSON such as customer orders, product categories, attributes and variations, you name it.
I started off by installing a Bitnami WordPress virtual machine, in which I could run the Apache server for a mock WordPress website in a guest OS instead of running it in the local machine. I needed to enable HTTPS connection to the website, so that I could use HTTP Basic Authentication, as it is needed for authentication purposes when interfacing with WooCommerce REST API. Hence, I created a self-signed SSL certificate for the server, but the problem was that it still does not authorize my cURL commands. With Dr Shawn’s help, it turns out that the issue is an Apache server issue, whereby it does not pass authorization headers by default. Here is the fix and hopefully saves you a headache if you’re setting up an Apache server for the first time : https://support.deskpro.com/en/kb/articles/missing-authorization-headers-with-apache
Now a crucial aspect of the web application that I’m gonna be working on is to automatically extract JSON data whenever certain events occur in the online store. WooCommerce enables you to do this through Webhooks. For example, if a customer has created an order for your products, a Webhook for that particular event will make a POST request to a specified URL, which in this case it will be to my simple HTTP server that I would set up. Its all cool and dandy but there were issues that needed to be addressed such as when:
- Server is down (say, for maintenance)
- Server returns a 4XX HTTP status code when receiving the request
- Server returns a 5XX HTTP status code when receiving the request
The question is how would the Webhooks react when one of the above happens? Would it attempt to deliver the failed deliveries again for each new delivery, or will they be lost forever? After experimenting with all three cases, I could say that the failed deliveries are still stored. The Webhooks keep a log of up to 25 recent deliveries, and you can see which of them are the failed ones. We could still retrieve information from the failed ones if we know their IDs.
POCO library
This is what I used to set up a simple HTTP server for testing and figuring out purposes. It basically just handles Webhook deliveries and parse and extract data from the received JSON. To be honest, this library is so much more convenient to use than the Wt framework, that we have considered using it for the entirety of the back-end development. Of course one clear disadvantage of this library is that it can’t do front-end development, while Wt have widgets for you to play with. In addition, since I am more familiar with Wt::Dbo, i.e their ORM database module, I’m going to just stick to that.
Besides JSON parsing and extracting, I also needed a way to authenticate the HTTP requests to ensure it is receiving the correct payload from a particular Webhook. In the headers of each Webhook POST requests, there is a custom header called X-WC-Webhook-Signature, in which it holds a base64 encoded HMAC-SHA256 hash of the payload.
As of now, the version of the library that we are using only supports SHA1 cryptographic hash function. We have seen, from its source code on Github, that support for SHA2 and even SHA3 were already there, but it is to be bundle in their latest version which has not been released yet. I had considered purely using the OpenSSL library to generate the hash, but Dr Shawn advised me to create a SHA256Engine class that derives from the DigestEngine base class in the POCO library. Therefore, I encapsulated the OpenSSL functions in the methods that are required to be implemented from the base class. By doing this, it makes my code more maintainable, as the class interfaces would not change even when SHA2 is finally integrated with the library. By combining my own SHA256Engine class and the HMACEngine class of the library, is was able to generate the message digest. Finally, I used the library’s Base64Encoder class to encode the digest in base64, thus obtaining the required hash to authenticate against the Webhook delivery signature.
I would officially start working on the project on the first day of next week. The next thing I would have to touch on with POCO is making e-mails using the library’s SMTP classes. Futhermore, I should come up with a basic design for that component of the system that deals with Webhooks, saving data into the database and sending e-mails to the customers before actually implementing it, just to get a clear big picture.
0 Comments