topic Prime 3.2 API and curl not working correctly in Controllers

Prime 3.2 API and curl not working correctly

tajennings — Fri, 07 Jul 2017 17:29:35 GMT

Hello,

I recently upgraded from Prime 3.0 to 3.2 and am having issues with using curl and php curl when trying to pull information using the filtering. For example:-

>curl -k "https://<user>:<pass>@<server>/webacs/api/v3/data/AccessPointDetails?macAddress=\"<mac>\""

Curl error: Empty reply from serverurl

The same result with using php curl.

When using curl to obtain a list of devices without using a filter, it returns the results fine.

On PI 3.0 this was working fine so I'm not sure what changed in 3.2. I tested a sample Ruby script and that works fine so even more weird!

Any thoughts on what is going on?

Re: Prime 3.2 API and curl not working correctly

Spencer Zier — Fri, 07 Jul 2017 20:31:27 GMT

My apologies, it seems there's been a regression here. I've opened CSCvf16644 to track this issue (the link may say the bug does not exist at first, it may take a couple business days for the bug to be visible).

Workaround

You can replace the \" escaped double-quotes with percent encoded double quotes. For example macAddress=%2200:11:22:33:44:55%22

I'll update this thread when I have information about when and in what patch this issue will be fixed.

EDIT: Bug now visible

Re: Prime 3.2 API and curl not working correctly

tajennings — Mon, 10 Jul 2017 13:24:05 GMT

Thanks for the reply and for opening a bug ID on this. I never thought of that workaround!

I had written an app (mostly for mobile) to interact with Prime and once I made the changes per your workaround, it is now working again.

Re: Prime 3.2 API and curl not working correctly

Spencer Zier — Mon, 10 Jul 2017 17:51:10 GMT

We've concluded our investigation into this issue; unfortunately, we'll be closing the bug (indicating that we believe the reported issue is valid but will go unfixed).

In PI, we use Apache Tomcat to handle our HTTP traffic. In resolving CVE-2016-6816, Tomcat's behavior was changed to strictly enforce RFC 3986's allowed URL characters. So, whenever an unencoded character is present in a URL, Tomcat will now immediately return an HTTP 400 response. This seems to occur before filters are invoked, which means we don't have that avenue to alter Tomcat's behavior. Furthermore, we can't identify any Tomcat configuration we'd be able to specify to workaround this particular issue.

So because this change in behavior was made to mitigate a vulnerability, and because the workaround is easy to implement, and for the reasons above, we're closing this bug. We will be making documentation changes to clarify things, but the behavior will go on as it is in 3.2.

I understand this is probably not the answer you wanted to hear; please feel free to reach out here or via email (my address is visible to logged in users on my profile) if you'd like to discuss this further.

Re: Prime 3.2 API and curl not working correctly

Spencer Zier — Mon, 17 Jul 2017 20:50:40 GMT

One more (and probably the last) update on this issue. We've updated the 3.2 Reference Guide and Tutorial in DevNet regarding this. We've also incorporated these documentation changes in the first maintenance release of 3.2

Re: Prime 3.2 API and curl not working correctly

tajennings — Mon, 17 Jul 2017 20:58:49 GMT

This is terrific news Spencer! Perfectly understandable in regards to the encoding of special characters in the URL. it's better to force the API clients to use correct encoding.

Re: Prime 3.2 API and curl not working correctly

iportuga — Mon, 04 Sep 2017 14:43:34 GMT

Hi,

You could try use curl with "--data-urlencode" parameter. See curl man page.

Re: Prime 3.2 API and curl not working correctly

Spencer Zier — Tue, 05 Sep 2017 15:23:35 GMT

Igor,

My understanding is that --data-urlencode only changes data in a POST/PUT request payload, not the URL. So I don't think it will help with this issue.

Re: Prime 3.2 API and curl not working correctly

iportuga — Thu, 14 Sep 2017 20:43:00 GMT

Hi Spencer,

Actually, you misunderstood some points regarding curl --data-urlencode option.

Take a look the follow example for an unauthenticated request (just to catch the HTTP headers):

# curl -k -G -v "https://10.129.223.18/webacs/api/v3/data/AccessPointDetails" --data-urlencode "apMacAddress=0c:85:25:34:5f:55" --data-urlencode "profileName=#MY-SERVICE WIFI"
* About to connect() to 10.129.223.18 port 443 (#0)
*   Trying 10.129.223.18...
* connected
* Connected to 10.129.223.18 (10.129.223.18) port 443 (#0)
* found 149 certificates in /etc/pki/tls/certs/ca-bundle.crt
*      server certificate verification SKIPPED
*      compression: NULL
*      cipher: AES-128-CBC
*      MAC: SHA1
> GET /webacs/api/v3/data/AccessPointDetails?apMacAddress=0c%3A85%3A25%3A34%3A5f%3A55&profileName=%23MY-SERVICE%20WIFI HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.27.0 GnuTLS/2.12.23 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 10.129.223.18
> Accept: */*
>
< HTTP/1.1 302
< Cache-Control: private
< Expires: Wed, 31 Dec 1969 21:00:00 BRT
< Set-Cookie: JSESSIONID=E9BCB19C2D40282961C6C2A6A7891650; Path=/webacs; Secure; HttpOnly
< Location: https://10.129.223.18/webacs/pages/common/login.jsp
< Content-Length: 0
< Date: Thu, 14 Sep 2017 20:28:54 GMT
< Server: Prime
<
* Connection #0 to host 10.129.223.18 left intact
* Closing connection #0

Request attibutes:

apMacAddress=0c:85:25:34:5f:55

profileName=#MY-SERVICE WIFI

Request URI:

/webacs/api/v3/data/AccessPointDetails?apMacAddress=0c%3A85%3A25%3A34%3A5f%3A55&profileName=%23MY-SERVICE%20WIFI

Re: Prime 3.2 API and curl not working correctly

Spencer Zier — Thu, 14 Sep 2017 20:45:09 GMT

I stand corrected