Having a problem with CURL and the HTTP User and password Auth methods, it is not liking the exclamation mark, I've tried escaping the following ways:
Tried and failed...
/usr/bin/curl -u 'UserName\WithSlash:PasswordWithExclamation!' https://test.com/
/usr/bin/curl -u UserName\\WithSlash:PasswordWithExclamation\! https://test.com/
Not working for basic or digest if it matters (using --anyauth) ... getting 401 denied...
What am I doing incorrectly?
curl -u UserName\\WithSlash:PasswordWithExclamation\! http://....
works fine.
it sends
GET / HTTP/1.1
Authorization: Basic VXNlck5hbWVcV2l0aFNsYXNoOlBhc3N3b3JkV2l0aEV4Y2xhbWF0aW9uIQ==
User-Agent: curl/7.21.0
Host: teststuff1.com:80
Accept: */*
which is "UserName\WithSlash:PasswordWithExclamation!" in the auth string.
not that complicated, just use "". at least it works on Linux.
for example:
curl -u "username:passwdwithspecialchar" GET https://....
If you know the server supports Basic auth, you could set the header directly:
curl --header "Authorization: Basic $(base64 --wrap=0 credentials)" https://example.org
This way you can store the user and password (UserName\WithSlash:PasswordWithExclamation!) without any escaping in the credentials file you pass to the base64 command.
Related
I have a script that uses the Azure DevOps API to retrieve every work item in a query. Then it retrieves the metadata for each work item. It requires a PAT. Until today the PAT has worked. I believe it is expired. I created a new PAT, but every attempt to retrieve the same information is unauthorized (401).
The cURL command in my script that worked until now:
ado_token={username#company.com:PAT, all Base-64 encoded as one string}
curl -X GET -H "Authorization: Basic $ado_token" -H 'Cache-Control: no-cache' "https://dev.azure.com/{company}/{project}/_apis/wit/wiql/{query ID}?api-version=5.1"
Here are the facts:
Going to the URL directly in the browser succeeds.
The new token is in the same project as the URL.
The new token has full access.
Microsoft documentation on ADO PATs provides this example:
curl -u username[:{personalaccesstoken}] https://dev.azure.com/{organization}/_apis/build-release/builds
However, when my username and PAT are entered with a URL I know to be correct, it is unauthorized.
Both in the format of the Microsoft example and the URL I would like to use in my script, these are all unauthorized in all iterations of Bearer and Basic. The URL used works in the browser:
{username}:{PAT}
{username}#{company}.com:{PAT}
Base-64 encoded {PAT}
Base-64 encoded {username}#{company}.com:{PAT}
Base-64 encoded pat:{PAT}
Base-64 encoded {username}:{PAT}
Base-64 encoded {username}#{company}.com:{PAT}
I have tried both in the command line and Postman but no added information was provided.
Am I missing something obvious? The most confusing aspect of this is that the previous PAT worked in this same code. Thank you for any help.
Try the command below:
curl -u :{PAT} 'https://dev.azure.com/{company}/{project}/_apis/wit/wiql/{query ID}?api-version=5.1'
In the -u parameter the Username field must be blank and the PAT is the original string.
Thus the command would be in the following format:
curl -u :lplnqn4l4glwqkslsfel7t2wjevfi5tayuiwm772qeawbwo3ztua 'https://dev.azure.com/acme/projetx/_apis/wit/wiql/6cbbddb4-f752-453b-9f98-f523470826fe?api-version=5.1'
Postman
using Authorization without username: Choose Basic Auth. and enter the PAT as password.
using Headers: Use key as Authorization and value as Basic {Base-64 encoded pat{:PAT}}. Note that {:PAT} needs to be base64 encoded
Curl
using basic authentication without username: curl -u :{PAT} https://dev.azure.com/{org}/_apis/projects
using headers: curl -H 'Authorization: Basic {Base-64 encoded pat{:PAT}}'
https://dev.azure.com/{org}/_apis/projects
I am trying to get a response from Microsofts Office 365 Management API using bash curl commands-
I get the token like this-
TOKEN=$(curl -X POST "https://login.microsoftonline.com/$TENANTID/oauth2/token" -d "grant_type=client_credentials&client_id=$CLIENTID&client_secret=$ACCESSCODE&resource=$RESOURCEURL" | jq -r '.access_token')
And then use the token to fetch the data like this-
RESULT=`curl -X GET -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://manage.office.com/api/v1.0/$TENANTID/ServiceComms/Services`
I do get a token back with the first command, so that works fine and my tenant/client/resource strings are correct
But the second one always gives
{
"error":{
"code":"","message":"Authorization has been denied for this request."
}
}
I pretty sure I have access-
What am I missing?
Turns out the resource URL i was using did not match the URL i was requesting data from
I am trying to obtain an authorization code from a Spring OAuth 2.0 authorization server using simple CURL command.
curl -v --header "Authorization: Basic hasfhfashfakhsfakhf712641246" "http://0.0.0.0:0000/oauth-server/oauth2/authorize?response_type=code&client_id=dummyclient&client_secret=dummyclient&redirect_uri=http://oauth2server/oauth2callback/"
However, instead of getting back a redirect URL with the code, I am getting back a 302 redirect response to the login URL. Since I am already sending the username, password in the Authorization Header, is there a way to skip the login page redirect and get the Authorization Code directly?
you might need to tell curl to follow redirect with the -L flag
curl -L -v --header "Authorization: Basic hasfhfashfakhsfakhf712641246" "http://0.0.0.0:0000/oauth-server/oauth2/authorize?response_type=code&client_id=dummyclient&client_secret=dummyclient&redirect_uri=http://oauth2server/oauth2callback/"
In Google's documentation for the Drive REST API v3, they provide the following "example" for how to upload a file to Drive using the "simple upload" method:
POST /upload/drive/v3/files?uploadType=media HTTP/1.1
Host: www.googleapis.com
Content-Type: image/jpeg
Content-Length: number_of_bytes_in_file
Authorization: Bearer your_auth_token
JPEG data
I am trying to construct a curl POST request to upload a .csv to Drive. I have tried the following (as well as countless variations), with no success. It keeps returning with an Error 400 (bad request)!!! error:
curl -s "https://www.googleapis.com/upload/drive/v3/files?uploadType=media HTTP/1.1" -H "Authorization: Bearer $access_token" -H "Content-Type: $mime_type" -H "Content-Length: $file_size" -d "$file" -X POST
For reference, the variables are defined as:
file_size="$(du -b $file | awk '{ print $1 }')"
mime_type=$(file -ib "$file")
Anyway, Google doesn't explain the "JPEG data" part, and I suspect that is where my curl POST request is wrong.
I've found a bunch of relevant examples on both here and Github, but none of them worked for me (all of the ones I found were outdated, anyway). I also tried multipart uploading, but I also couldn't get that to work (and again, most of the examples here seemed outdated).
Just trying to play with google app scripts. In anonymous mode things seem fine. Except that anyone can call my script simply like that snippet shows:
curl "https://script.google.com/macros/s/.../exec?ip=\"$myIp\""
I used this manual for tips on how to authenticate through GoogleLogin. The problem is "401 Unauthorized" I received when sent auth token and "Me(owner)/Only myself" options were set on google side. (The token seems correct itself. If I omit password or mistype it, then I receive "Bad auth") If I set "Anyone, even anonymous" again, it works, but auth stuff seems like ignored. What's the correct way to do the trick?
#!/bin/bash
gmail=$1
password=$2
myIp=$3
GoogleAuthToken=""
GoogleAuthToken=`curl --silent https://www.google.com/accounts/ClientLogin --data-urlencode Email=$gmail \
--data-urlencode Passwd=$password -d accountType=GOOGLE -d source=YouDontSay -d service=lh2`
echo $GoogleAuthToken
GoogleAuthToken=$(echo "$GoogleAuthToken" | grep 'Auth=' | sed s/Auth=//)
echo $GoogleAuthToken
curl -L --silent --header "Authorization: GoogleLogin auth=$GoogleAuthToken" "https://script.google.com/macros/s/.../exec?ip=\"$myIp\""
You use ClientLogin
https://www.google.com/accounts/ClientLogin
This is google error :
Important: ClientLogin has been officially deprecated since April 20,
2012 and is now no longer available. Requests to ClientLogin will fail
with a HTTP 404 response. We encourage you to migrate to OAuth 2.0 as
soon as possible.