I have a Google Search Appliance and am trying to access the API to download the Event Logs. I am using curl through cygwin on the Windows 7 command line.
I am able to get an authentication token using
curl -X POST -d Email=username -d Passwd=password "http://ip.ad.dr.ess:8443/accounts/ClientLogin"
My problem is that when I attempt to retrieve the even logs themselves:
curl -k -X GET -d query=User -H "Content-type: application/atom+xml" -H "Authorization: GoogleLogin Auth=e73265ce254f7c4afbcbee1743a56e81" "http://10.29.5.5:8000/feeds/logs/eventLog"
curl says that it cannot reach the host:
curl: (7) couldn't connect to host
Any help in getting this to work is greatly appreciated.
Check if you can telnet to the IP-address. If you get a timeout there you should check firewalls etc.
C:\> telnet 10.29.5.5 8000
This looks like a more generic network problem than a problem with either the GSA or Curl.
The problem turned out to be the configuration with my GSA. The GSA is configured to require communication over HTTPS. Because all GSAs default to HTTP traffic over port 8000 and HTTPS traffic over 8443, my problem was solved by sending the following:
curl -k -X GET -d query=User -H "Content-type: application/atom+xml" -H "Authorization: GoogleLogin Auth=e73265ce254f7c4afbcbee1743a56e81" "https://ip.ad.dr.ess:8443/feeds/logs/eventLog"
Related
I am working with Nginx Plus API and trying to put the backend servers in drain mode and while doing this via curl getting below error ,
"method":"PATCH","error":{"status":415,"text":"json error","code":"JsonError"},
format which I followed :
.\curl.exe -u username -X PATCH -d '{"drain":true}' baseserverurl
have to use as -X PATCH -d '{\"drain\":true}'
I'm using openam OAuth/OpenID for user authentication. As mentioned in the documentations, I could get SSOTokenID as a JSON object by making following HTTP request.
curl -X POST -H "X-OpenAM-Username: demo" -H "X-OpenAM-Password: changeit" -H "Content-Type: application/json" -d '' -k -v https://openam.example.com:8443/openam/json/authenticate?realm=/
Instead of that, I want to get SSOTokenID as the Set-Cookie header value of the HTTP response. Are there anyway that i can do it?
Assuming you are only using an authentication module that accepts a NameCallback and PasswordCallback (as you used in your example), then you can just use the legacy UI zero-page login , you need to disable XUI though
Using your example
curl -X POST -d 'IDToken1=demo&IDToken2=changeit' -k -v https://openam.example.com:8443/openam/UI/Login?realm=/
curl -X GET --header 'Accept: application/json' --header 'Authorization: Bearer 90d2c018-73d1-324b-b121-a162cf870ac0' 'https://172.17.0.1:8243/V1.0.2/stock/getNA?name=te'
The terminal prompted
"curl: (51) SSL: certificate subject name (localhost) does not match target host name '172.17.0.1'
"
However, after I changed the "172.17.0.1" to "localhost", it worked and I got the result.
Why? Is there a wrong configuration somewhere?
Meanwhile, there isn't any log information in file http_access.log.
When SSL handshake happens client will verify the server certificate. In the verification process client will try to match the Common Name (CN) of certificate with the domain name in the URL. if both are different host name verification will fail. In your case certificate has CN as local host and when you try to invoke using IP address, it fails. When you create the cert you can have single host name / multiple host name / wild card host name as CN value
For more details, see:
Fixing Hostname Verification
What is the SSL Certificate Common Name?
CN of the default WSO2 certificate is localhost. Therefore you have to use localhost as the hostname when you send requests. Otherwise, the hostname verification fails.
If you want to use any other hostname, you should generate a certificate with that hostname, as Jena has mentioned.
I actually had this problem and found a fix:
I was requesting a URI like 'http://some.example', but the variable for HTTPS was set to '1'
I had this problem when trying to pull from a Git directory after I'd added a new SSH key and my Git repository moved.
In the fray, Git's CN got confused. The solution for me was to delete the git directory and re-clone it via SSH. As the other users hinted at, you can't change the CN of a website's certificate, so you'll have to change the setting on your computer that has the wrong CN, or avoid using HTTPS (and use SSH like I did).
As others have hinted, this is failing because the TLS negotiation checks that the cert matches the hostname in the URL.
What's new is that curl now supports this scenario via a connect-to option. So, if your curl is sufficiently new (v7.18.1) this should work:
curl -X GET 'https://localhost/V1.0.2/stock/getNA?name=te' \
--header 'Authorization: Bearer 90d2c018-73d1-324b-b121-a162cf870ac0' \
--header 'Accept: application/json' \
--connect-to localhost:443:172.17.0.1:8243
Credit: https://stackoverflow.com/a/50279590/1662031
Similarly you may be able to leverage curls resolve option:
curl -X GET 'https://localhost:8243/V1.0.2/stock/getNA?name=te' \
--header 'Authorization: Bearer 90d2c018-73d1-324b-b121-a162cf870ac0' \
--header 'Accept: application/json' \
--resolve localhost:443:172.17.0.1
When I try to curl using the -T option, I get an empty reply:
$ curl --digest -u me:pwd -H "Content-Type:application/xml" -T test.xml http://localhost:8085/
curl: (52) Empty reply from server
Anyone know the incantation? The server works fine when connecting to it from the WebDAV client built into MacOSX.
By default curl sends Expect: Continue, but unfortunately java web containers don't play nicely with the Expect header. The simplest answer is to instruct curl not to send that header:
curl --digest -u a2 -H "Content-Type:application/xml" -H "Expect:" -T TestPBE-workspace.xml http://localhost:8080/users/a2/files2/
The better solution is to make expect:continue work, but from the research i've done it appears that depends on what web container you're using.
In my nginx.conf I have this line in my server {} section:
log_format debug 'header: "$http_x_myapp" cookies: "$http_cookie"';
Then if I do
curl -H "X_MYAPP:test" -H "COOKIE:yay" localhost
I get something like this in my access log:
header: "-" cookies: "yay"
Does anyone know why nginx is throwing away the X_MYAPP header?
Oops... I'm stupid.
curl -H "X-MYAPP:test" -H "COOKIE:yay" localhost
works... stupid underscores...
The correct way to send cookies with curl is with the -b options:
curl -b 'yay' http://localhost