Rest API Fatal Errors

[safemoon]

Username:

TITLE

Rest API Fatal Errors

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.68 Update #2 Web Host Edition
Ubuntu 24.04.2 LTS

PROBLEM DESCRIPTION

Hello,

Creating a new thread as suggested from this post

Issue - GetDatabases Rest API Fatal Error

Hi All, Recently the API call to the /databases endpoint is not working properly without a "domain" parameter. It used to work without any issues before. Having the ability to find if a database name already exists in the server is very beneficial as it allows you to create databases/domains...

talk.plesk.com

I've encountered issues with the Plesk REST API endpoints /databases and /dbusers when invoked without specific parameters. Previously, these endpoints functioned correctly without requiring additional parameters, but recent behavior suggests otherwise. I suspect that similar issues may be present in other endpoints as well.

STEPS TO REPRODUCE

Issue with /databases Endpoint:
Request: GET /api/v2/databases
Response:

  {

      "code": 0,

      "message": "PleskX\\Api\\Operator\\Database::getAll(): Argument #1 ($field) must be of type string, null given, called in /opt/psa/admin/plib/modules/rest-api/v2/library/SDK/pm_Database.php on line 47"

  }

This suggests that the domain parameter, which was previously optional, is now required.

Issue with /dbusers Endpoint:
Request: GET /api/v2/dbusers
Response: Error indicating that the dbId parameter is missing.

This implies that the dbId parameter has become mandatory, whereas it was optional before.

ACTUAL RESULT

Causes a fatal error when the domain or dbId parameters are not passed.

EXPECTED RESULT

The response when the parameters are not passed should contain ALL database users and database names
These parameters were optional, and there were no such issues.

ANY ADDITIONAL INFORMATION

Impact:
These changes affect the ability to programmatically verify the existence of databases and database users without specifying domain-specific parameters. This limitation complicates remote management tasks, such as creating databases or domains without conflicts, as it necessitates additional API calls and processing

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Help with sorting out

 

[Sebahat.hadzhi]

Thank you for the report, @safemoon . Our team is still instigating the matter and this is an intermittent status update. The XML they suggest is:

curl -k -X GET https://10.69.43.49:8443/enterprise/control/agent.php -H "Content-Type: text/xml" -H "HTTP_AUTH_LOGIN: admin" -H "HTTP_AUTH_PASSWD: setup1Q**" --data-binary @get-db.xml

Where get-db.xml has an empty filter:

root@10-69-45-222:~# cat get-db.xml
<packet>
<database>
<get-db>
<filter>
</filter>
</get-db>
</database>
</packet>

As mentioned in the following document Available Filters is valid for all (databases in this case) and the result will show all databases.

 

[Kaspar]

@Sebahat.hadzhi, I suspect there might be confusion about this issue as the initial bug report might not be completely clear. The proposed solution from the team related to the XML API, while the issue @safemoon is referring to is related to the REST API. I am not sure if that's clear to the team. For what's it's worth I've been able to replicate this behavior too.

To partially clarify the issue a bit more an example might be useful for further investigation. When calling the database method on the REST API, like for example:

curl -X 'GET' \
  'https://server.hostname.plesk:8443/api/v2/databases' \
  -H 'accept: application/json' \
  -H 'authorization: Basic ABCDEFG='

The response is:

  {
      "code": 0,
      "message": "PleskX\\Api\\Operator\\Database::getAll(): Argument #1 ($field) must be of type string, null given, called in /opt/psa/admin/plib/modules/rest-api/v2/library/SDK/pm_Database.php on line 47"
  }

While the expected response is a list of all databases. There has been an issue with the API database method is the past, but caused by something different (I think): Resolved - REST API: Unable to retrieve all databases via databases endpoint

(I haven't tested the dbusers method issue described by @safemoon. That seems to be an separate issue worth investigating).