4.9 - Problem with universal module, URL notifcation

[breeze]

Hi all,

I have recently upgraded to 4.9.1. After upgrade it seems there is an issue with the URL notification in the universal API.

If a package is using the universal module - and the module has anything in the URL notification field - I can't use any packages/services at all, including creating a service that is using this module/product.

Sorry if this is confusing - take a look at the image. If there are any values in these fields, nothing can be done. If I remove them, everything is normal.


Troubleshooting:

- I have tried multiple URLS

- I have different Blesta instances, both are performing the same

 

Is anyone else experiencing this?
Is there a way that I can troubleshoot?

 

Thanks in advance.

[Paul]

Do you have any errors in your logs when this happens?

../logs_blesta/ (Path is defined under Settings > System > General)

What version of PHP and MySQL are you running?

[Jono]

On 5/2/2020 at 1:54 AM, breeze said:

If there are any values in these fields, nothing can be done. If I remove them, everything is normal.

What do you mean when you say "nothing can be done"?  What happens?  Do you get a white screen?  An error message?  It succeeds but no notification is sent? What exactly is happening?

[breeze]

Hi guys,

Thanks for the response, I could have put some more info in there.

- PHP 7.2.25

- mysql  Ver 15.1 Distrib 10.3.20-MariaDB

 

There has only been one error generated - despite multiple attempts, so I am not sure how relevant
 

[2020-05-10 12:19:03] general.ERROR: PDOException: SQLSTATE[70100]: <<Unknown error>>: 1927 Connection was killed in /var/www/html/vendors/minphp/db/src/PdoConnection.php:196 Stack trace: #0 /var/www/html/vendors/minphp/db/src/PdoConnection.php(196): PDOStatement->execute(Array) #1 /var/www/html/vendors/minphp/record/src/Record.php(763): Minphp\Db\PdoConnection->query('SELECT COUNT(*)...', Array) #2 /var/www/html/vendors/minphp/record/src/Record.php(862): Minphp\Record\Record->fetch() #3 /var/www/html/app/app_model.php(0): Minphp\Record\Record->numResults() #4 [internal function]: AppModel->validateExists('1', 'id', 'staff') #5 /var/www/html/vendors/minphp/input/src/Input.php(541): call_user_func_array(Array, Array) #6 /var/www/html/vendors/minphp/input/src/Input.php(362): Minphp\Input\Input->validateRule('staff_id', Array, '1', 'staff_id') #7 /var/www/html/app/models/logs.php(270): Minphp\Input\Input->validates(Array) #8 /var/www/html/components/modules/module.php(1129): Logs->addModule(Array) #9 /var/www/html/components/modules/universal_module/universal_module.php(1317): Module->log('https://webhook...', false, 'output', true) #10 /var/www/html/components/modules/universal_module/universal_module.php(1173): UniversalModule->sendHttpNotice('https://webhook...', Array, '', '') #11 /var/www/html/components/modules/universal_module/universal_module.php(263): UniversalModule->sendNotification('service_notice_...', Array, '1', NULL, Object(stdClass)) #12 /var/www/html/app/models/services.php(3342): UniversalModule->suspendService(Object(stdClass), Object(stdClass), NULL, NULL) #13 /var/www/html/app/controllers/admin_clients.php(5322): Services->suspend('342', Array) #14 /var/www/html/vendors/minphp/bridge/src/Lib/Dispatcher.php(142): AdminClients->editService() #15 /var/www/html/index.php(21): Dispatcher::dispatch('/admin/clients/...') #16 {main}

 

For the sake of testing I am managing the service via the admin login. E.g. http://server.com.au/admin/clients/editservice/1/342/

This is what happens:

- I make changes to the status of the service and hit save

- the web page starts loading and then hangs. Eventually I get a 405 (about 60 seconds). I then need to refresh the page to get back to the admin screen

- the status change is applied correctly

- the URL endpoint does not receive a notification

 

I'd appreciate any help you can offer.

 

[breeze]

Hi all,

I found the issue. Apparently our server provider implemented some new anti-fraud thing, and it was blocking outbound requests. So because I had a URL in the post notification of the universal module, the request wasn't making it out to the endpoint and the whole process was failing.

Thanks for the input.

 

[Paul]

6 hours ago, breeze said:

Hi all,

I found the issue. Apparently our server provider implemented some new anti-fraud thing, and it was blocking outbound requests. So because I had a URL in the post notification of the universal module, the request wasn't making it out to the endpoint and the whole process was failing.

Thanks for the input.

 

That's very interesting, thanks for the update! Any idea on what they are using to block outbound requests? Did they just block the http port (80/443) egress at their firewall? Maybe this will be helpful for someone else in the future.

[breeze]

Hi Paul,

Yes - it was blocking outbound 80/443. It was intended to deter hackers that are trying to access our server in order to use them as part of their pool of servers - so even if they gained access it would seem pointless to them.

Only way I figured it out was setting up an endpoint on another server with the same hosting provider and testing over their LAN. ?‍♂️

I don't know how hard it is to adjust the core functionality to allow the order to proceed if the API POST fails? I'd much rather take the customer order and figure the rest out later rather then letting the process fallover.