MTA and REST API woo's

I spent the majority of my day today trying to get our MTA Server to be able to post threads to the forums.

Way back when, Maxime used to directly SQL inject the threads into the forum database. This is a security issue, opening up our forum database to more hosts, but also unreliable.
Any updates to the IPB software could cause the structure to change and create issues for how we inject threads to the database. This wasn't an issue back then because Maxime would never update the forums, but now that I update our forums within a week of new versions being release, this is no longer practical.

Luckily IPB does include a REST API that we could tap into.

MTA does have a cURL module which can be used to make REST API calls, however it is only developed for windows platforms and we run solely on linux in our production servers.

So, our only solution was to get it to work with MTA's built in functions or create our own MTA cURL module, like we did with bcrypt.

So today I tried my best to use the MTA functions, both callRemote and fetchRemote. callRemote would not work for our purposes so fetchRemote became the next best thing to try.

Using PostMan I created an API call and did some testing which worked fine.
Postman

Moving onto the MTA side of things we used a url_encoder to handle the form data that would be passed in the body of the call.
url_encode.lua

I still could not get it to work as IPB would return a 400 Bad Request error stating it could not find some of the required parameters, even though they were being passed.

So I took a look at the request through WireShark:
Wireshark

Everything looked fine, so I compared it to what was successfully being passed with PostMan:
Postman wireshark

The difference was that the content-type header was being set to application/x-www-form-urlencoded which could then be properly processed by IPB..

Since fetchRemote to my knowledge does not support setting headers, it looks like this was a big waste of time trying to get this to work properly.