Script parameters and curl authentication

[AVmcclint]

I have a script that uses an ID & PW with curl and it works perfectly when I run it locally. When I define $4 as username and $5 as the password (with the respective values in the policy) and run the script in Jamf it just hangs and I can't figure out why.

curl -u username:password https://company.com... works perfectly when run locally. It also works in Jamf, but I'd rather not put the credentials directly in the script.

curl -u $4:$5 https://company.com... does not work when run from Jamf.

I have tried variations like $4 : $5 or "$4" : "$5" or '$4' : '$5' or "$4":"$5" or '$4':'$5' 

I've even verified the values with a line that says echo $4 $5 and it does report the values correctly.

However, if I define variables in the script like $acct=username and $pw=password and use  $acct:$pw in the curl command, that works just fine, but once again, I'd rather not put the credentials directly in the script. It seems that I can't get the variables to work when defined in Jamf.

 What am I missing?

[TryingEverythi]

First option:

Parameter 4 = Username:Password

This is the jamf setting 

add the code:

auth=$(openssl enc -base64 -d <<< "$4")

curl -u "$auth" https://company.com...

Second Option:

Parameter 4 = #Encoded UserName:Password in base64

This is the jamf setting 

add the code:

auth="$4"

curl -u "$auth" https://company.com...

[mm2270]

Have you tried curl -u "$4:$5" https://company.com ? Meaning enclosing $4:$5 in double quotes?

Also, IF this is for the Jamf API (not clear from what you mentioned), then you really should look at moving to use the token method of authenticating. Even if using username:password with the API works now, eventually it won't. If this is for something other than accessing Jamf Pro API, then ignore what I'm saying.

[TryingEverythi]

For API it needs more information example

curl -k -s -u "$APIauth" -X "PUT" "https://$jamfserver/JSSResource/computers/udid/$getudid/subset/extension_attributes" \ 

-H "Content-Type: application/xml" \ 

-H "Accept: application/xml" \ 

-d "<computer><extension_attributes><extension_attribute><id>$eaID</id><name>$eaName</name><type>String</type><value>$value</value></extension_attribute></extension_attributes></computer>"   exit 0

but the above two options might work - i didn't tested it

[sdagley]

On the question of when Basic Authentication is going away here is what the Jamf Pro 11 release notes star in the Deprecations and Removals section:

"Support for Basic authentication will be removed in March 2024."

For users on Jamf Pro 10.49 or later you should take a look at the API Roles and Clients functionality added in 10.49 which is intended to replace the older mechanism of granting access to an user account: https://learn.jamf.com/bundle/jamf-pro-documentation-current/page/API_Roles_and_Clients.html

[AVmcclint]

I had forgotten about the bearer token option. It is more complicated, but it actually worked with the $5 defining the APIaccount password.  

To give full context, I'm tired of our Apple Silicon Mac users being able to just choose not to authenticate when we try to force OS updates so I'm building a script that will use our LAPS password that is generated and saved by an Extensions Attribute. It does this by querying the computer record and using xpath (ugh) to find the value of the specific extensions attribute. Then the script takes that LAPS password and uses it with the softwareupdate command with --user and --stdinpass options. So far it works as intended.