This is what I tried:
curl http://git.ep.petrobras.com.br/api/v3/session --data-urlencode 'login=myUser&password=myPass'
Answer:
{"message":"401 Unauthorized"}
The problem is the data-urlencode CURL option. Since it's an HTTP POST you don't need to URL encode the data, and is actually encoding the & into & and causing your issue. Instead use the --data option.
curl http://git.ep.petrobras.com.br/api/v3/session --data 'login=myUser&password=myPass'
Also, be careful sending credentials over plain HTTP. It could be easily sniffed.
This is how:
$ curl http://git.ep.petrobras.com.br/api/v3/session/ --data-urlencode 'login=myUser' --data-urlencode 'password=myPass'
The solution pointed out by Steven doesn't work if your username or password contains characters that have to be urleencoded. The name=content format will urlencode the content part (the name part has to be urlencoded but login and password are fine).
To actually retrieve the private_token you can pipe the output of curl into jq like this:
$ curl [as above] | jq --raw-output .private_token
x_the_private_token_value_x
This way you can easily use it in a shell script.
Also, as Steven pointed out already, please use https instead so that your password is not transmitted in clear text across the wire.
Note: this workflow no longer works as of GitLab 8.6.0 as the default password has been removed.
Changelog: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG#L205
I only just noticed this and raised the issue. Leaving this note here to hopefully save someone else some time. Hopefully, this is a decision that will be reviewed and reverted.
Discussion/issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/1980
Related
I need to run some test that use a NTLM proxy.
Due to Karate doesn´t support NTLM proxy, I think that if karate can "execute" a curl command like below, I will get kate working with NTLM:
curl -X GET 'https://someaddress.com/cats?Status=completed' -u siteuser:sitepasswd --proxy-ntlm --proxy-user ckuser:ckpasswd --proxy internal-ntlm-proxy:8080 -s
Anyone knows if I can call a curl command in Karate? (instead of the internal http request that Karate use when call Given... Path...)
Thanks
Yes, Karate has very good CLI support, if curl is present on your OS, it can be done. See this answer for details, available in 0.9.6 https://stackoverflow.com/a/62911366/143475
In your case, try first with karate.exec()
* def result = karate.exec("curl -X GET 'https://someaddress.com/cats?Status=completed' -u siteuser:sitepasswd --proxy-ntlm --proxy-user ckuser:ckpasswd --proxy internal-ntlm-proxy:8080 -s")
And result will contain the console text. Note that there are regex helpers to make scraping values out easier, for e.g.:
* def token = karate.extract(result, 'some(pattern).+', 1)
I'm using a raw post since I'm using react native and I didn't see a react-native library.
I'm getting a 403 response when trying to upload using the raw upload form post- is there a setting that I need to set or is my public key not activated or something? I don't see a text response in the 403 response so not sure what the specific error is.
Here's my sample CURL from postman
curl -X POST -H "Content-Type: multipart/form-data; boundary=..."
-F "UPLOADCARE_PUB_KEY=foo"
-F "UPLOADCARE_STORE=1"
-F "file=#logo.jpg" "https://upload.uploadcare.com/base/"
Here are few things you should look at:
content-type is not needed here
reason for 4xx should be stated in response body or headers
make sure that you don't have typos in API key
make sure that automatic storing is enabled in the project or send "UPLOADCARE_STORE=auto"
make sure that your account is not blocked, has some quota left, file type is allowed, etc.
don't rely on Postman, check the command with cURL
This works:
curl -vv -X POST \
-F "UPLOADCARE_PUB_KEY=demopublickey" \
-F "UPLOADCARE_STORE=1" \
-F "file=#logo.png" "https://upload.uploadcare.com/
I see you are trying to use multipart upload, how big is logo.jpg? Are you able to upload the same file using the dashboard?
I try to fetch some data from a Microsoft Dynamics Nav WebService.
This service uses the NTML authentication.
If I open the webservice url in a browser and use the given credentials everything works fine.
For setting up the environment for the WebService Client, I used the command line to check whether everything is working fine, I was, at a specific point, unable to authenticate.
Thats the command I am using:
curl --ntlm -u "DOMAIN\USERNAME" -k -v "http://hostname:port/instance/Odata/Company('CompanyName')/Customer"
The command will prompt for the password.
I copy in the password and everything is doing fine.
But when I use this command, with the password already included, it stops working and the authentication fails:
curl --ntlm -u "DOMAIN\USERNAME:PASSWORD" -k -v "http://hostname:port/instance/Odata/Company('CompanyName')/Customer"
The password contains some special chars, so I tried to use the percent encoding, which had no effect at all.
It is very difficult to research this kind of issue. Searching for curl + ntlm authentication issues provides a lot of results, but nothing is related to this specific kind of issue.
Does anyone of you guys already had experience with this kind of issue?
I had a problem with authentication because of cookies. I solved this containing cookies in txt file and using exactly this file through all requests. For example, after login request I saved this cookies:
curl -X POST -u username:password https://mysite/login -c cookies.txt
And with next request I used this file like this:
curl -X POST -u username:password https://mysite/link -b cookies.txt
This solution worked for me, I don't know if your problem is similar, but, I think, you may try this.
I was struggling with similar issue for a long time and finally I found this curl bug report #1253 NTLM authentication fails when password contains special characters (british pound symbol £) .
NTLM authentication in cURL supports only ASCII characters in passwords! This is still the case in version 7.50.1 on Ubuntu but I tested this on many different distributions and it is always the same. This bug also will break curl_init() in PHP (tested on PHP7). The only way to solve that is to avoid non ASCII characters in NTLM authentication passwords.
If you are using Python then you are lucky. Apparently Python developers rewrote cURL implementation and it works with non ASCII characters if you use HttpNtlmAuth package.
Try with nltm flag.
Something like this:
curl -v --proxy-nltm -u 'username:password' youproxy.com:8080 someURL
from > curl --help
-x, --proxy [PROTOCOL://]HOST[:PORT] Use proxy on given port
--proxy-anyauth Pick "any" proxy authentication method (H)
--proxy-basic Use Basic authentication on the proxy (H)
--proxy-digest Use Digest authentication on the proxy (H)
--proxy-negotiate Use Negotiate authentication on the proxy (H)
--proxy-ntlm Use NTLM authentication on the proxy (H)
I've problems adding an SSH key to my gitlab server trough the API (It works well trough the webpage).
Gitlab information:
I came across this issue (which was fixed here) which was related to an "wrong" openssh implementation. They've fixed this in milestone 7.10. Only thing... My server has openssh 6.6 installed:
OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3, OpenSSL 1.0.1f 6 Jan 2014
Now, I don't know if that fix is backwards compatible or not, but maybe good to mention.
Also, the logs show no warning or errors or whatsoever. The /tmp/gitlab_key* files are generated on the server:
The problem I'm facing is that gitlab can't create the fingerprint trough the API. This is the responce I get from the API:
{
"message": {
"fingerprint": ["cannot be generated"]
}
}
So right now I have no idea what the problem could be. I've been struggling with this for almost a week now, so I really hope that his problem could be fixed.
-just for the record, here's the script I'm using to add the ssh-key trough the API
#!/bin/bash
jsonFile="jsonResponce"
echo `curl http://gitserver/api/v3/session --data 'login=****&password=****'` > $jsonFile
userToken=$(jq '.private_token' $jsonFile)
finalUserToken=$(echo "$userToken" | tr -d '"')
echo "user token: $finalUserToken"
# Below key is for testing, will use output of cat ~/.ssh/id_rsa.pub later on
# sshKey="ssh-rsa AAAAB3N***** ****#***.com
# curl --data "private_token=$userToken&title=keyName&key=$sshKey" "http://gitserver/api/v3/user/keys"
rm $jsonFile
id_rsa.pub is base64 encoded file, it contains + character
http post with application/x-www-form-urlencoded, need encode it's content preventing + being convert to (space)
try
curl --data-urlencode "key=$key_pub" --data-urlencode "title=$hostname" \
http://gitlabserver/api/v3/user/keys?private_token=$Token
see: this
Improving on #Mathlight's answer the following snippet uploads public ssh key to gitlab.com
curl -X POST -F "private_token=${GITLAB_TOKEN}" -F "title=$(hostname)" -F "key=$(cat ~/.ssh/id_rsa.pub)" "https://gitlab.com/api/v3/user/keys"
OP here
In the mean time I've updated the server to version 8.8 and changed the curl code a bit and now it's working like a charm:
curl -X POST -F "private_token=${userToken}" -F "title=${sshName}" -F "key=${sshKey}" "${gitServer}/user/keys"
Just in case anybody needs this in the future...
I'm trying to use http PUT via cURL to update my triple store in openrdf-sesame, but I've hit a problem that I can't find a solution for.
When using POST, the triple data uploads perfectly.
But then using PUT, instead of adding the data provided, it deletes all the data from my repository. I've ran cURL in verbose mode, and it's giving back the expected HTTP status code.
I've added
<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
to Apache Tomcat's web.xml,
Ive also tried the guide here: HTTP PUT Guide, but that hasn't helped either.
EDIT
Here are the cURL commands from my batch file:
call "%curl%" -# -X POST %endpoint%/statements -H "Content-Type:application/x-trig;charset=UTF-8" -d #%%X
call "%curl%" -# -X PUT %endpoint%/statements -H "Content-Type:application/x-trig;charset=UTF-8" -d #%%X
Which is essentially:
curl.exe -# -X POST http://myendpoint/statements -H "Content-Type:application/x-trig;charset=UTF-8" -d #MyTrigFile.trig
curl.exe -# -X PUT http://myendpoint/statements -H "Content-Type:application/x-trig;charset=UTF-8" -d #MyTrigFile.trig
For the moment, I've disabled authentication, but otherwise I'd also include a -u user:password argument.
I have just ran some tests using your exact way of invoking curl, and I can't reproduce the problem (using Sesame version 2.6.8): it works as expected here.
The only possible cause I can think of is that your TriG file has a syntax error which Sesame fails to report back.
Another possible problem is your expectations: the command as you execute it will completely clear the entire repository and replace the data with the contents of your TriG file. Were you perhaps expecting something else?
To further debug this, can you have a look in the Sesame server logs and tell us if it shows any warnings or errors? Server logs are viewable by going to http://<server:port>/openrdf-sesame/ in the browser and clicking 'System' in the menu on the left.