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)
Related
I have problems to get Bearer access token in Jmeter. Problem's cause most probably is in
server authentication - do not really understand how to properly setup this in Jmeter.
curl consist of several parts:
curl -X POST -v https://xxxx.xxx.xx.lv/token -u
"d123c9e3-4e91-46db-931e-37e8a52b8c8d:0e7cb8ad50fe3686de05fcf46815abc0a9d7cd095c23f75446d933ccxyxy"
-d "grant_type=password" -d "username=xxxxxxx" -d "password=xxxxxx" -d "scope=scop"
I have tried to use HTTP AuthorizationManager, HTTP Request and HTTP Header Manager without any successful results. Any advices?
Thanks!
Tatjana
I think you should do something like:
HTTP Request sampler:
these protocol and Server Name bits can be moved to HTTP Request Defaults so you won't have to specify them for each and every HTTP Request sampler
HTTP Authorization Manager:
In general since JMeter 5.1 it's possible to create a test plan from curl command line, the option lives under "Tools -> Import from cURL" main menu entry:
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)
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
With a linux, I send a curl message like that:
curl -X POST -d "hello" http:/server_adress
the server is a Windows. I would like to find "hello" in my Apache log but I don't know how to do this.
Do you think the curl is correct ?
What do I have to put in my php file to see "hello" in my apache log ?
I find the answer.
the message curl have to be like this:
curl -X POST -d "message = hello" _http://server_adress
and in the file php.
$message=$_POST["message"];
write_debug_log("$message);
It returns "hello" in the apache log
Your curl command is okay. Its now you to the server log(and the administrator) to check the data on the log.
So far I know the data(means post data) doesn't come to by default in the log. You need to configure it from the log setting or something like that(if it is possible).
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.