I can interact with my open search docker container via curl -XGET https://localhost:9200 -u 'admin:admin' --insecure but no use when I want to automate requests to it... I need to be able to access it, even via HTTP is fine (not secure meaning not HTTPS).
command:
curl -XGET https://localhost:9200
error:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
I did go into that link, not a solution, just an explanation that threw me into a rabbit hole I was able to get out just now.
The awful thing is that this happened to me before and I fixed it, but it was not on a docker container and I don't remember how I fixed it.
You can disable security in your Dockerfile then:
RUN echo "plugins.security.disabled: true" >> /usr/share/opensearch/config/opensearch.yml
Your OpenSearch will be accessible via http://localhost:9200 after. I do this to setup my data, and then load /usr/share/opensearch/data in an other container set up with security.
Related
I have docker application running on my desktop and also OWASP zap also running on my desktop. how would i configure OWASP ZAP so that any request going out will be intercepted and response be modifyed before it goes to the docker app.
Its more about how you configure your docker app than how you configure ZAP. ZAP listens on a host and port. You need to make sure that you can access that host:port from your docker container (you can just use curl to the host:port and see if that returns anything). Then you need to configure your app to proxy through ZAP. You might be able to do that within your app (if it supports proxies) or you might need to play around with the networking.
We have a company proxy (ip:port) and need to send HTTP POST with json payload to the URL like "http://server1.smthng.com/foo". Locally, name could not be resolved, but it is resolved at proxy. I dont understand how to configure haproxy to use proxy "ip:port" and send request without modifying the original URL.
I've tried curl to "http://server1.smthng.com/foo" after setting https_proxy variable from CLI (in linux) and it worked for me, so now I need to replicate same via haproxy.
From curl logs I could see that it first makes a CONNECT to proxy and once connection is there it POSTs the data.
I could be missing some knowledge here regarding tcp tunnels and the answer could be simple really. Anyway, need help.
The question is to be closed with no asnwer. The solution we took is via civetweb htt_proxy parameters.
I was asked to secure my stateless api endpoint using cert based authentication. I read about the subject, and realized I needed to create a middleware to inspect the request, and then check for the x-ARR-ClientCert header, to check whether the certificate is valid or not, based on some thumbprint. So far, so good.
The problem is that I can't test the middleware, because I don't have idea on how to send such a header. I already have a self signed certificate(.crt) and a key(.key). I tried with postman, but I can't see the x-ARR-ClientCert being sent while debugging on VS2017.
Any Help?
Edit 1
I'm following this tutorial: https://blogs.msdn.microsoft.com/kaevans/2016/04/13/azure-web-app-client-certificate-authentication-with-asp-net-core-2/
I know it's a bit old, but at the end the writer shows the browser asking for a certificate, but I just can't manage for the browser to ask for the certificate.
One thing I forgot to mention here, is that my API is on a local Service Fabric Cluster, so that might be the problem
Edit 2
For Postman, I've followed this tutorial: Postman Tutorial, but had no luck: first I had to turn off ssl check, and then when added the certificate to Postman, the x-ARR-ClientCert header wasn't being sent.
I've also tried curl: > curl --cert cert.crt --key client.key https://localhost/api/values --insecure but still the x-ARR-ClientCert isn't being sent.
I am not sure what you are trying to accomplish...
In a mutual certificate authentication, the browser handles the authentication\certificate exchange, and when the user tries to access an endpoint secured by client certificate, the server tells the client(browser) that it requires a certificate to accept the connection and the browser popup a message to the user asking for a certificate to be used, there is a nice write about it here.
If the plan is to do it for automation, the postman blog has an article on how you setup client certificates for this scenario. The other option is trying to send the certificate using CURL as described here.
Secondly, you are reinventing the wheel, there are already some ready to use implementations in kestrel using HttpsConnectionAdapterOptions.ClientCertificateMode = RequireCertificate and some authorization middlewares here and here.
And finally, make sure that there is no proxy in the middle or that the proxy or gateway is not removing the certificate from the client connection.
I'm trying to download the bits of a Cloud Foundry app using the Cloud Foundry API.
https://apidocs.cloudfoundry.org/236/apps/downloads_the_bits_for_an_app.html
When using a remote blobstore, such as AWS, the response is a redirect to the actual location of the bits. If the client is automatically following redirects, then the OAuth token that was used to communicate with Cloud Controller will be replayed on the new redirect request. Some blobstores may reject the request in that case. Clients may need to follow the redirect without including the OAuth token.
Here is my cURL command I'm attempting to use:
$ curl -L "https://api.my.host.net/v2/apps/my_app_guid/download" -X GET -H "Authorization: bearer myauthtoken"
curl: (7) Failed to connect to dal05.objectstorage.service.networklayer.com port 443: Operation timed out
I'm assuming my issue is that my Auth header bearer token is being sent on the redirect based on the quote from the Cloud Foundry API docs. How can I follow the redirect without the OAuth token? I'm using the default cURL command line utility on Mac OS X 10.11.
While #DanielStenberg's comment appears to be correct that the header wasn't my issue, I'll go ahead and provide an answer to my original question.
It appears the only way to follow the redirect without headers would be to NOT immediately follow the redirect, but print the response headers with the curl -D - command option. Once you get the 301/302 response from the original request, check the location header value that came in the response headers, then execute another curl to that location.
I have setup serverend points they work for the web interface fine but the api endpoint for my for app do not even give a error and does not time out.
I have tried turn the app to production mode in the web interfaces no joy.
I look at the doc for server setup but can find any thing to help.
So I would think their is configure issue where should I look?
On localhost ever thing works.
On remote host where using 168.192.0.15:8530 only web interface works not my api form either curl or may app
Without further information I can only guess what the problem is, but I'll try:
The default --server.endpoint configuration value for an ArangoDB server is tcp://127.0.0.1:8529. That means you will be able to access it from the local machine but not from other hosts.
To make the server respond to HTTP requests originated from other hosts, you will need to use an endpoint that includes the server's IP address as used in your network, e.g. tcp://192.168.173.13:8529 and restart it with the adjusted configuration.
If that's not working either, can you trying calling the target URL from another server via curl and check the server's HTTP response code. This might reveal the source of the problem, too. Note that you should invoke curl with the option --dump - to see the HTTP response code. For example:
curl -X GET --dump - http://192.168.173.13:8529/your/app
If that is not producing any results (i.e. no response at all), you might have a firewall in between that blocks requests. Probably you need to allow access on the port ArangoDB uses (8529 by default and used in my example).
So I have learn the issue is the api endpoint url is not the same on localhost at their are from outside. Example:
curl -X GET --dump - http://localhost:8529/broad/broad/login
curl -X GET --dump - http://192.168.0.15:8530/_db/_system/broad/broad/login
https://docs.arangodb.com/cookbook/MakingFoxxAppAccessible.html
This lead me to my answer