As I see in this article:
https://www.docusign.com/blog/dsdev-adding-webhooks-application
that in Sandbox mode we can config webhook url with HTTP but when I go to my account Setting section it won't let me use HTTP
So my question is how can I use HTTP in sandbox mode for testing purpose.
Unfortunately you can't use HTTP with Connect
This guide explains it https://developers.docusign.com/esign-rest-api/guides/connect-https-only
Quote from Q&A
"DocuSign Connect is used to transmit sensitive data about your envelopes across the Internet. As part of DocuSign’s focus on security, we are upgrading all notifications to use HTTPS only."
Hope this answer your question
Related
On this page: https://developers.docusign.com/esign-rest-api/code-examples/webhook-status, the last section is called: There’s more. And there you can read that there are 3 ways to check that DocuSign is making the web hook request:
you can check the SSL/TSL certificate of the webhook caller (DocuSign).
set DocuSign to digitally sign the data
DocuSign publishes the IP address ranges
If we examine all these options we have:
This is false, you can't check the SSL certificate of who is making the request to you. SSL certs are designed to be used by clients connecting to servers to check that there is no man in the middle attack. And only the client can verify the cert of a server, not the other way around.
I can't find on the page any mention how to set the signature, and most importantly, how to check it.
The link provided to the Public IPs: https://trust.docusign.com/en-us/trust-certifications/ip-ranges/, does not work.
My questions are:
Where can I find some documentation about the signature process?
Where is the page with the public IPs?
The best way to do that is to create an HMAC key and use that to confirm that the calls are authentic.
Here is a full article on how to do that - https://developers.docusign.com/esign-rest-api/guides/connect-hmac
Thank you for reporting the out of date documentation. I've filed an internal bug report, DEVDOCS-1565, to have it updated.
As Inbar says in his answer, these days, the best solution is HMAC. You can also combine it with Basic Authentication if you're using DocuSign webhooks at the account level.
HMAC gives you the guarantees that the message did originate from DocuSign and that the message was not altered in transmission.
Don't set up a server on the Internet
The old way of receiving webhook messages was to set up a server that is accessible on the public internet. Due to the costs and Information Security issues creating and maintaining a service on the Internet, these days I suggest that you skip it.
Instead, use a cloud PAAS (AWS, Azure, Google Cloud, etc etc) to receive and queue the messages. Then, from behind your firewall, you can dequeue and process them. (With no changes to your firewall.)
See the Connect- series of code examples.
Mutual TLS for checking the client's certificate
Note that you can check the certificate of a client. This feature of the TLS (ne SSL) protocol is called Mutual TLS and is supported by DocuSign webhooks.
But HMAC is better since it also guarantees message integrity.
For the Azure CLI, is there a way to use proxy authentication? Our proxy servers needs all requests to be authenticated and I do not see any document relating. Using HTTP_PROXY environment variable, I can instruct the az cli to use a particular proxy server but I cannot define it to use proxy authentication, OR if there is a way to do this, I do not know. Our Proxy authentication has to be done either through NTLM or Kerberos.
Can the relevant team, please check If we can configure az cli to use Kerberos proxy authentication?
The root of the answer lies in the fact that Azure CLI is built on top of Python. Now as regards Authentication, Azure CLI uses AAD based protocol, which is handled by the ADAL library for Python whose source code is published here.
So if this is of interest and someone wanted to see the wire level details, please dig in here.
As mentioned Azure CLI is built on TOP of python, one of the reasons being to give it a broad cross-platform reach, as it available across Windows, Mac, Linux (and may be other ports are available).
And ADAL Python is based on a popular Python HTTP library. While the proxy can be configured (and that is not the question here), what was asked and what enterprises want is a way to use Kerberos/NTLM to authenticate the requests while funneling it through a proxy. So if you dig into the documents for the Python HTTP library, you can see named requests, whose proxy support can be configured inline or by environment vars (again that is not the ASK).
Now when you dig into authentication when requests are being proxied, the document mentions HTTP basic auth only, and there is no mention of Kerberos/NTLM type of authentication. Now if one has worked with any security conscious enterprise, this would be difficult to get an exception. This has been requested by some enterprises, where they want to authenticate (security requirement) all Azure CLI requests at their external facing proxies before it leaves the perimeter.
The current answer is there is not a supported way to do this, unless an auth handler is implemented that does this, for the scenario where a proxy is in place. This is a request that would squarely belong to the Python HTTP library owners, if I am not mistaken.
For anyone still looking for the answer to this question the answer can be found here
# Non-authenticated HTTP server:
HTTP_PROXY=http://10.10.1.10:1180
# Authenticated HTTP server:
HTTP_PROXY=http://username:password#10.10.1.10:1180
# Non-authenticated HTTPS server:
HTTPS_PROXY=http://10.10.1.10:1180
# Authenticated HTTPS server:
HTTPS_PROXY=http://username:password#10.10.1.10:1180
Obviously not the most secure approach and be careful to url encode any special characters.
In my case I had to remove protocol "http|https" from variable string
# Non-authenticated HTTP server:
HTTP_PROXY=server.fqdn.int:8080
# Non-authenticated HTTPS server:
HTTPS_PROXY=server.fqdn.int:8080
I am trying to get DocuSign Connect to make HTTP Post request to my URL.
I have done some testing with POSTMAN app on google chrome and I am able to process the DocuSign XML Messages sent through this HTTP Post Request.
Attached is my setup.
I am unable to receive any messages from DocuSign (I have tried both sending and signing) and additionally I do not see any logs under Logs or Failures.
Is there any possible reason for this?
Updates: I was using a Self-Signed Certificate on my application and hence DocuSign was unable to post the XML message to my web service.
This has been resolved after installation of a DocuSign accepted certificate.
Assuming your account is configured properly for Connect and you do not see anything in the logs or failures here's some possible reasons:
Security software or firewall on your side blocking/catching the message before it reaches your listener
You are filtering for an envelope you do not have permission to.
Your tests are invalid (i.e. you've configured for a signing event but the user is declining or taking some other action).
Also, I just realized you don't have Require Acknowledgement enabled in your Connect config- try turning that on to see if any failures start showing up. Here's the description from the docs of this option:
"Require Acknowledgment: Select this option to log posting failures. DocuSign waits 100 seconds for an acknowledgement before recording a failure. DocuSign logs a failure if the attempt to reach the external endpoint returns anything other than an HTTP 200. The acknowledgment failure messages are logged on the Failures page, which is accessed by clicking FAILURES on the Connect page. When this option is selected, DocuSign will automatically attempt to repost any failures. You can also manually repost from the Failures page."
Check that you have "Connect" enabled as one of the account's features. Do this using the admin tool (New DocuSign Experience) or Preferences in Classic.
Also, if you're trying out Connect on a production account, only some types of accounts include the Connect feature. Contact your Account Manager if it isn't enabled.
All Developer Sandbox accounts on the demo platform do include Connect.
All account types support webhook subscriptions at the envelope level using the eventNotification feature.
Are you using production account or sandbox account for docusign connect.. You must include the protocol HTTP or HTTPS in the web address for sandox account and you must include HTTPS:// in the web address for Production accounts because SSL is required in Production account. Docusign Connect sends the xml to the default ports of 443 for HTTPS: and 80 for HTTP. If you cannot use port 443 for Production contact DocuSign to review possible options. Check this link for docusign connect technical information.. Hope you have handled the server side of it (i.e, the url which you have mentioned in the URL to publish) inorder to get the response from the docusign to the desired url when some event happens..
For example:
If you are using sandbox docusign account for Connect means, URL to publish as to be something like this http://domain.com/Home/DocuConnect (Hosted application port number as to be 80). For sandbox account,docusign connect are enabled defaultly for all the users.
If you are using production account for Connect means, URL to publish as to be something like this https://domain.com/Home/DocuConnect (Hosted application port number as to be 443). In some cases docusign connect are enabled based on the respective subscription plans. To check that go to features tab see for Docusign Connect and try to tick the checkbox and if it is not checked then you got to contact the Docusign Account Manager.
We are having issues with Connect notifications from our DocuSign demo account.We are not able to receive any updates from our Connect configuration. Though, when I republished the XML from Connect logs, I did receive a Connect update to a specified URL.
When I created new envelopes using API as well as from DocuSign account itself, I never got any notifications to the same URL.I do not even see a Connect log.
We do not have any issues with Connect notifications for our DocuSign live account.
We have never experienced this issue before with Connect updates from our DocuSign demo account.
Please advise.
Just a hunch - do you use http or https? connect can only work over port 443 with a valid SSL certificate. If you're on localhost - you may need to get a temp certificate or something like that but also using azure websites is good way to avoid this issue since they're pretty much just as good as working on your localhost
I am recieving a "org.apache.http.conn.HttpHostConnectException: Connection to https://demo.docusign.net refused" exception when trying to connect to start the embedded signing envelope request using serverside java HTTP call with a proxy server in between.
Is there a limitation of the number of requests per hour?
DocuSign imposes a limitation of 1,000 API calls per hour for an account. See the DocuSign API Best Practices Guide for information about this limitation: http://www.docusign.com/sites/default/files/SOAP_REST_API_Best_Practices_with_Connect_Guide.pdf.
I was using a HTTP proxy instead of a HTTPS proxy, the proxy in between me and docusign was causing the issue.