Jump to content
  • 0

4.9 - Problem with universal module, URL notifcation


breeze

Question

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.

Screen Shot 2020-05-02 at 6.48.42 pm.png

Link to comment
Share on other sites

6 answers to this question

Recommended Posts

  • 0
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?

Link to comment
Share on other sites

  • 0

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.


 

Link to comment
Share on other sites

  • 0

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.

 

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0

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.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...