The major thing that I managed to get done by this week was the implementation of interfacing with the WooCommerce REST API. As a reminder, this is only done by the application when a new subscription for an organization certificate is made, and the customer also chooses the option to entrust the management of their certificate to us, hence their intermediate CA certificate will be stored on our server side. This intermediate CA is responsible for issuing client certificates that are to be used by the members of such organization. The only way for their members to obtain their client certificate, is by buying a subscription for the organization’s client certificate on the WooCommerce store, which also interfaces with our application. The WooCommerce REST API would be used to create a draft product as well as a coupon code that is tied to that product on the fly. The purpose of the coupon code is for the members of the organization to obtain the certificate for free. All in all, it is merely for the sake of convenience for us, saves us the trouble of creating a new product just for that organization manually, and also we could easily tell when an order for an organization product has been made.
It was not too difficult to get this functionality underway. Just consult the REST API docs, understand what kind of parameters are needed and how to make the HTTP request. The only setback I had was with the boost::property_tree library to serialize a JSON payload to be used as part of the request to the REST API. The problem with it is that, the library encodes everything in JSON as a string, so other data types like int or bool are not supported. Some parameters in the JSON needs to be of a non-string type, so I had no choice but to change the JSON library. Wt’s JSON APIs were thankfully easy to use. Anyways, of course the structure of the JSON payload that is required to create the draft product and the coupon was in their own separate JSON file and not hardcoded within the source code. Those JSON templates are read into memory as the application starts up, so the necessary key and value pairs are modified in runtime before the request gets made to the WooCommerce store.
So that’s all good in that regard. Dr Shawn, however, informed me that WordPress 5 has just been released. I’m not sure if I have to make any major changes for interfacing with the REST API, but hopefully it is not too drastic. Other than that, I had to make the application handle other webhooks as well, which are the Subscription Switched, and Order Restored webhooks. For Subscription Switched, the same endpoint as for Subscription Updated can be used, thus following the same application flow as when a new subscription is being made. I have checked that the JSON payload for that webhook is the same as Subscription Updated. On the other hand, the Order Restored webhook is needed for us to retrigger the webhook and replay the whole application flow for the case when a webhook fails to be received by the application for some reason. This is triggered when an order is moved to trash using the WordPress Dashboard interface, and is then subsequently restored. We had done this in a previous project of ours, i.e CRS. However, the problem is that deleting the order in this case would also delete the subscription that is tied to the order. When the order gets restored, so does the subscription, but that subscription would be in a cancelled status, and could not be changed to any other that status from that point, which is definitely not what we want. The only alternative way that this could be done, as I have tried out, would be to temporarily suspend the affected subscription and then reactivate the subscription.
The only required functionality I have yet to implement, at this point, is to find a place in the certificates to store extra meta data, or “features” as Dr Shawn coined it. These “features” would probably have to be stored in an x509v3 Certificate Extension, but I would have to figure out how to do that with Botan C++, since they only support a handful of those extensions, and they have specific usages. When that is out of the way, I should be done implementing the required functionalities of the application. I would also re-attempt to implement the automatic certificate installation into the user’s browser after that. Of course, some further testing and code refactoring are also essential at the end. But I am getting there…
0 Comments