404 errors caused by double // in JSS URL string

[AllPurposeBen]

Hey Team,

I noticed recently that this script was failing (and failing silently, which was kind of scary but a separate issue for another time) when trying to talk to my JSS to update the EA with the new password. It was getting 404 returns. Confirmed my API account was good and did a little more digging and found this issue, bear with me:

Issue Confirmation and Troubleshooting

When trying to read the EA initially for the getCurrentPassword function, when ran with a bash -x, I see the curl it was trying to do was (with sensitive info redacted):

curl -s -H 'Authorization: '<redacted token>' -H 'Accept: text/xml' https://<redacted-subdomian>.jamfcloud.com//JSSResource/computers/serialnumber/<redacted-serial>/subset/extension_attributes

I noticed the // between the FQDN and the rest of the resource path and tried the curl again manually with a single / and was back in business, the // there was the issue.

Root Cause Investigation

I tracked back in the script and found that the JSS url is being determined as:

JAMFURL=$(defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url)

...which when run on my machine returned https://<redacted-subdomian.jamfcloud.com/, notably with the trailing slash.

Tentative fix

I'm not sure if something changed on the API end to make the // fail or if Jamf made a change to the stored jss_url value to include the trailing slash when it wasn't there before. I was able to get things back to working by a slight tweak to line 98:

JAMFURL=$(defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url | sed 's:/*$::')

...that trims the trailing slash if present and got things working for me again.

Thoughts? Am I on to something and/or has anyone else seen issues with getting 404's back from Jamf when trying to read/update the EA?