Error with spaces in API calls

[mjhersh]

I'm writing an API script to retrieve information about applications, and I'm having problems with applications that have spaces in their names. The usual URL encodings (+ or %20) don't work with the API. If I paste the application name into the /api web interface, it show that it's converting them to %20, but it returns no data, and I'm seeing the same results with curl.

For example, let's take Photoshop CS6.

curl --user <api_user> -X GET '<casper_url>/JSSResource/computerapplications/application/Adobe%20Photoshop%20CS6.app' # returns empty xml
curl --user <api_user> -X GET '<casper_url>/JSSResource/computerapplications/application/Adobe+Photoshop+CS6.app' # returns empty xml
curl --user <api_user> -X GET '<casper_url>/JSSResource/computerapplications/application/Adobe Photoshop CS6.app' # returns nothing

The only way I can get actual results is if I use wildcards in place of the spaces, like this:

curl --user <api_user> -X GET '<casper_url>/JSSResource/computerapplications/application/Adobe*Photoshop*CS6.app' # returns legitimate results

That's NOT an effective workaround, because it has the potential to match multiple apps, which is not what I want. For example, if someone had an app called "A 6.app", that search would match "Adobe Photoshop CS6.app" if I used wildcards. That's no good, especially since application names are arbitrary and can be changed by the end user (even accidentally).

Is the API broken? Is there a workaround? Am I the only one seeing this behavior?

Thanks.

[mm2270]

Enclose the entire JSS Resource URL in double quotes and forget about trying to encode the space to see if that works. It should in my experience. IOW, try it like:

curl -H "Accept: text/xml" -u <apiusername:apipassword> -X GET "<casper_url>/JSSResource/computerapplications/application/Adobe Photoshop CS6.app"

Right now you have it enclosed in single quotes which doesn't do the same thing.

I'm not in front of a machine to give this a try, but try it and see if the results come back for you.

[mjhersh]

Thanks for the suggestion. Unfortunately, I get the same results with single or double quotes.

[SamF]

@mjhersh This appears to be a product issue with the Jamf Pro API, and has been filed as PI-004980. As you noted, the best workaround at this time is to utilize wildcards in place of any spaces or characters that would normally need to be encoded. I encourage you to create a ticket with Jamf Support and reference this thread and PI number.

[flyboy]

Have you tried converting your spaces to the '%20' that is supported by URLs?

I use the function below to encode strings like this before sending them. I take no credit for this function. I grabbed it off the internet somewhere, possibly here. Feed your url to this function and then take its output and feed that to the API.

#!/bin/bash

urlencode() {
    # urlencode <string>

    local length="${#1}"
    for (( i = 0; i < length; i++ )); do
        local c="${1:i:1}"
        case $c in
            [a-zA-Z0-9.~_-]) printf "$c" ;;
            *) printf '%s' "$c" | xxd -p -c1 |
                   while read c; do printf '%%%s' "$c"; done ;;
        esac
    done
}

[mm2270]

There's a nice simple perl command that does this

#!/bin/sh

variable="Adobe Photoshop CS6.app"

URLencoded=$(perl -MURI::Escape -e 'print uri_escape($ARGV[0]);' "$variable")

echo "$URLencoded"

result:

Adobe%20Photoshop%20CS6.app

Unfortunately, I can confirm that this still doesn't work. The only workaround in my testing does seem to be to use wildcards. So yeah, this functionality isn't working as expected, which is news to me, so good to know. I never pull application info from the API, so this doesn't affect me personally, but hopefully Jamf can address this sometime soon.