[Modify Api.php and DYNHost]: Correct path in php to use in GET/POST/DELETE functions of /ip/{ip}/
Opened this issue · 4 comments
This fantastic story is about how fantastic OVH has developed its proprietary programming in APIs. Terribly sad part of this story is how little OVH provided user friendly interface, examples or support until today. The example scripts provided are just not sufficient.
Only after a torturous playing with /Ovh/Api.php and firewall.php (created based on default php code from API website, code unchanged) with correct details to login, I found sending an input to /ip/{ip}/firewall/{ipOnFirewall}/rule from my server is useless as it contains dots in the URI query string (from an IP Address).
More details are here:
Get PHP to stop replacing '.' characters in $_GET or $_POST arrays?
https://stackoverflow.com/questions/68651/get-php-to-stop-replacing-characters-in-get-or-post-arrays
One solution is to have Api.php classes modified to convert dots into underscores at client, when it transmits the query string with dots. Thereafter, the receiving server reconverts the changed query string back into IPs, if underscores are found in /firewall parsing of strings. An advantage is that there is no vulnerability in this system.
Second solution is to provide clients a proper functioning php script. In the API, one finds proper php codes after login. They contain dots from IPs. Due to this "DOT in URL" nothing works.
Because OVH APIs provided those php codes, I thought that this problem of dots is taken care of. This is not the case. The script can login and fetch some data from the API path /me. But it does not do anything when an API call is made under php to /ip/{ip}. It gets stuck with dots in {ip} and throws an error with some explanation one takes time to understand .
One of the best solution is to provide a DYNHost function integrated with /ip/{ip}/firewall that could constantly feed in the actual IP of subdomain under DYNHost to sequence 0 every day. A customer could choose under DYNHost if the latest IP should be inserted into /ip/{ip}/firewall/{ipOnFirewall}/rule/{0}. By doing so, all customers shall have their Routers IP automatically inserted into Rule 0 of all firewalls.
In the absence of the above DYNHost function, all clients are required to undergo a torturous deleting and creating IP under Rule 0 for each firewall by making ten - 15 clicks. Had it been there, a customer could bind services to a specific IP, which could then bind and route to a customer's Router IP. With this system, a customer could have secure access to admin services at non-public and non-standard ports directly bound to his Router IP every day. This increases security and ease to use firewall as all admin services are accessible to a customer's Router IP.
Thus, the suggestion is here not only to [Modify Api.php] but also create an extra API for DYNHost function.
Now I found where the problem is, while working with shell version to trigger JSON (after having problems in php version).
The problem is NOT in the dots from {ip}, as initially suspected. It is in the ipBLOCK given in path. When using ipBlock with /ip/32/ in php version, one gets an error: {"message":"Got an invalid (or empty) URL"}. This shows that /32 is an invalid URL given in path
In JSON, one could see that ipBlock in path is given as /ip%2F32/. Here when, I used in php version in /ip/32/, it gives an error. When I change path to have the JSON version /ip%2F32/, there is no error.
There should be some change in php version of scripts, which I do not know.
Hello @SchneiderDe ,
IP Address values need to be URL encoded to prevent to be understood as a new path parameter by the API.
Should I consider this issue as solved ?
I consider this issue resolved because @rbeuque74 reply with the answer concerning urlencoding and there is no reply after.
I did not find the need to reply because the mater was addressed without any testing with php scripts.
Further, since I circumvented the problem by using shell scripts. That does not mean that the issue is resolved.
Nor do I have any capacity to work with php problem any more. Thats your problem to investigate in-depth.
If I used something different and that was wrong, then there should be appropriate notice in comments in there. Entering an ip address, the error was thrown.
You could let remain this issue closed and wait for someone here to open, if they bang into the same problem, which I very much think they would.