I want to verify my pact against an API that has an https endpoint.
My request is timing out when I run the pact.
Does Pact.Net supports https verification or am I missing something?
Yes, it should be able to do this.
I'm going to guess that the https target is using a self-signed certificate. To work around that you can specify the following env vars to fix this:
To connect to a Pact Broker that uses custom SSL cerificates, set the environment variable $SSL_CERT_FILE or $SSL_CERT_DIR to a path that contains the appropriate certificate.
(see also https://github.com/pact-foundation/pact-ruby-standalone/releases)
You could enable debug logging to see what the process is doing, consult the docs on how to do that.
Related
I'm using com.microsoft.azure.kusto connect to kusto database for my project. However, my cluster is not in the format of <profile-name.region>. It's a proxy url (https://kusto.microsoft.com/). It doesn't seem to work and returns nothing. Just wondering does the library support connect to the proxy url?
Thank you.
Does the library support connecting to proxy url?
Please take a look at the comment by #Anera above.
Regardless, you can provide the authentication token to the client from the outside, using either AccessTokenTokenProvider or CallbackTokenProvider class. The audience to issue the token for should be "https://kusto.kusto.windows.net"
I'm using DocuSign's eSignature API. Rails app, server is nginx. I'm trying to get Mutual TLS working, with no luck so far. I used the instructions here.
I'm currently in DocuSign's sandbox - is there any reason Mutual TLS wouldn't work in the sandbox? I'm not seeing $ssl_client_fingerprint or $ssl_client_s_dn in my access_log.
Edit: I'm not getting any errors from nginx. Webhooks are working, I just don't see the client fingerprint, or $ssl_client_s_dn in my nginx logs. My lone question is: does mutual TLS with nginx work when webhook POSTs come from DocuSign's sandbox?
Edit 2: I figured out my issue. The nginx configuration was fine. I didn't have verify_ssl_host set to true when creating the DocuSign API client.
configuration = DocuSign_eSign::Configuration.new
configuration.host = base_path
configuration.verify_ssl_host = true # I was missing this
api_client = DocuSign_eSign::ApiClient.new(configuration)
Mutual TLS can work in the Developer Environment (also known as "Sandbox" or demo).
https://www.docusign.com/blog/dsdev-mutual-tls-stuff-know has more information about it.
If you need help with that - please provide more information about your issue.
I am creating a REST API in Go, and I want to build URLs to other resources in my replies.
Based on the http.Response I can get the Host and URL.
However, how would I go about getting the transport scheme used by the server? http or https?
I attemped to check if server.TLSConfig is nil and then assuming it is using http since it says this in the documentation for http.Server:
TLSConfig *tls.Config // optional TLS config, used by ListenAndServeTLS
But it turns out this exists even when I do not run the server with ListenAndServeTLS.
Or is this way of building my URLs the wrong way of doing things? Is there some other normal way of doing this?
My preferred solution when running http and https is just to run a simple listener on :80 that redirects all traffic to https. Then any real traffic can be assumed to be https.
Alternately I believe you can access a request's URL at req.URL.Scheme to see the protocol.
Or do you mean for the entire application? If you accept configuration to switch between http and https, then can't you look at that and see which they chose? I guess I'm missing some context maybe.
It is also common practice for apps to take a baseURL via flag or config to generate external urls with.
I am working with a historic API which grants access via a key/secret combo, which the original API designer specified should be passed as the user name & password in an HTTP Basic auth header, e.g.:
curl -u api_key:api_secret http://api.example.com/....
Now that our API client base is going to be growing, we're looking to using 3scale to handle both authentication, rate limiting and other functions. As per 3scale's instructions and advice, we'll be using an Nginx proxy in front of our API server, which authenticates against 3scale's services to handle all the access control systems.
We'll be exporting our existing clients' keys and secrets into 3scale and keeping the two systems in sync. We need our existing app to continue to receive the key & secret in the existing manner, as some of the returned data is client-specific. However, I need to find a way of converting that HTTP basic auth request, which 3scale doesn't natively support as an authentication method, into rewritten custom headers which they do.
I've been able to set up the proxy using the Nginx and Lua configs that 3scale configures for you. This allows the -u key:secret to be passed through to our server, and correctly processed. At the moment, though, I need to additionally add the same authentication information either as query params or custom headers, so that 3scale can manage the access.
I want my Nginx proxy to handle that for me, so that users provide one set of auth details, in the pre-existing manner, and 3scale can also pick it up.
In a language I know, e.g., Ruby, I can decode the HTTP_AUTHORIZATION header, pick out the Base64-encoded portion, and decode it to find the key & secret components that have been supplied. But I'm an Nginx newbie, and don't know how to achieve the same within Nginx (I also don't know if 3scale's supplied Lua script can/will be part of a solution)...
Reusing the HTTP Authorization header for the 3scale keys can be supported with a small tweak in your Nginx configuration files. As you were rightly pointing out, the Lua script that you download is the place to do this.
However, I would suggest a slightly different approach regarding the keys that you import to 3scale. Instead of using the app_id/app_key authentication pattern, you could use the user_key mode (which is a single key). Then what you would import to 3scale for each application would be the base64 string of api_key+api_secret combined.
This way the changes you will need to do to the configuration files will be fewer and simpler.
The steps you will need to follow are:
in your 3scale admin portal, set the authentication mode to API key (https://support.3scale.net/howtos/api-configuration/authentication-patterns)
go to the proxy configuration screen (where you set your API backend, mappings and where you download the Nginx files).
under "Authentication Settings", set the location of the credentials to HTTP headers.
download the Nginx config files and open the Lua script
find the following line (should be towards the end of the file):
local parameters = get_auth_params("headers", string.split(ngx.var.request, " ")[1] )
replace it with:
local parameters = get_auth_params("basicauth", string.split(ngx.var.request, " ")[1] )
finally, within the same file, replace the entire function named "get_auth_params" for the one in this gist: https://gist.github.com/vdel26/9050170
I hope this approach suits your needs. You can also contact at support#3scale.net if you need more help.
We have Jira 5.x running in the standalone variant (embedded tomcat). We'd like to prevent any request without a valid http basic header from reaching the Jira application. Or, in other words, force JIRA to use HTTP Basic authentication. Yes, I know that transmitting http basic credentials over the wire without tls isn't secure and stuff, but we don't have an SSL certificate anyway, so that doesn't matter (it doesn't make it worse than it actually is).
I read that Jira handles HTTP Basic Authentication headers if it gets them, and appending ?os_authType=basic to the URL makes Jira behave as we wish, but we'd like Jira to enforce HTTP Basic. We wouldn't care if we had some kind of "even-before-jira" login statically configured in tomcat as long as the jira application wouldn't be reachable from outside without it.
Is there a way to achieve this?
I tried adding:
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
to jira's web.xml but that didn't help.