Third party module hosting

[billsimon]

I’m trying to implement this to self-host a module: Third Party Module Hosting - FreePBX OpenSource Project - Documentation

It works up to the point where FreePBX goes to download the updated module (tar.gz) from the specified location. FreePBX sends a POST request for the download, (modulefunctions.class.php line 1533 from the FreePBX 16 framework), which is an unusual way of requesting a download. As a result it seems like I will have to write a script just to take these POST requests and return a file. Not ideal because I would like to just have the releases on github.

Anyone else here implemented third party module hosting? and worked around this behavior?

Why is FreePBX using a POST request here?

@miken32 sorry for tagging you but I’m tagging you 'cause your name is on it

[miken32]

No worries, I think I may have written the code in question years ago, after getting tired of manually uploading module files.

We’ve been running this internally for years, with just plain GET requests. As in the article, we use this in our XML:

<updateurl>https://download.example.ca/json/ourmodule.json</updateurl>

Then the JSON file has a “location” key pointing to the tgz archive:

{
  ...
  "location": "https://download.example.ca/modules/ourmodule-4.2.tgz"
}

This is what it looks like on the update server when I run fwconsole ma upgrade ourmodule on a PBX:

172.16.249.27 - - [10/Jul/2023:14:27:45 -0400] "GET /json/ourmodule.json HTTP/1.1" 200 4110 "https://download.example.ca/json/ourmodule.json" "php-requests/1.8.1" download.example.ca
172.16.249.27 - - [10/Jul/2023:14:28:06 -0400] "GET /json/ourmodule.json HTTP/1.1" 200 4110 "https://download.example.ca/json/ourmodule.json" "php-requests/1.8.1" download.example.ca
172.16.249.27 - - [10/Jul/2023:14:28:06 -0400] "HEAD /modules/ourmodule-4.2.tgz? HTTP/1.0" 200 - "-" "-" download.example.ca
172.16.249.27 - - [10/Jul/2023:14:28:06 -0400] "GET /modules/ourmodule-4.2.tgz HTTP/1.1" 200 74013 "https://download.example.ca/modules/ourmodule-4.2.tgz" "php-requests/1.8.1" download.example.ca

[billsimon]

Thanks for the tip. Now I see a discrepancy. It works differently from the command line using fwconsole ma upgrade module than it does if you pick the upgrade option from the list in the Module Update web page. The CLI way works but the GUI way doesn’t. I will keep troubleshooting.

apache log when I run it from the GUI: (404 here because I am just testing)

216.73.x.x - - [10/Jul/2023:14:57:07 -0400] "HEAD /module-16.0.9.tar.gz? HTTP/1.0" 404 5137 "-" "-"
216.73.x.x - - [10/Jul/2023:14:57:07 -0400] "POST /module-16.0.9.tar.gz HTTP/1.1" 404 39193 "https://referrer" "php-requests/1.8.1"

[miken32]

I get the same results when updating from the web UI; 2 GET requests for the JSON and then the HEAD and GET for the archive. Not sure why that code is in there to do a POST request, or why my system isn’t using it.

Is the 404 messing it up perhaps?

Our download server is firewalled for internal use only; otherwise I’d put up a module for you to test against our system with. I’ll take a poke through the code and see if I can determine what path the code takes, but this legacy stuff is pretty messy.

[billsimon]

I was not able to figure out the logic, though I did notice that the console version of the module update uses a function called handledownload to GET the file from the server, whereas the GUI version uses a function called download which has the POST method. Why? probably some unpaid technical debt. Clearly it works either way with the Sangoma mirror server.

Apache web server apparently doesn’t care whether you GET or POST for a static file so I have my workaround for now - I’ll serve the module from Apache.