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
Related
We went live with DocuSign integration a while back. In the development, we're able to authenticate the DocuSign credentials of the user and then they're able to send documents for eSign.
After going live, our customers trying to authenticate their DocuSign credentials on our app are getting URI not present error.
Any idea where we're going wrong.
You need to configure the key again in the production environment.
These URIs are not copied over for you even after you went live.
I am using the new msal.js for Single Page Applications (https://www.npmjs.com/package/#azure/msal-browser). The good news is I got it all working! So after logging in to azure ad I get redirected to my app with an access code and with that code msal is getting accesstoken/refreshtoken/idtoken from the azure code.
After this I am using the accesstoken to access my own web API that is hosted on my own on premise server. I am using spring boot in combination with azure-active-directory-spring-boot-starter. This all works fine too.
My question is: My server is contacting microsoft every time there is a request to the server.... why is this? It has got the JWT token from the request, the server knows clientid & client secret so why does it still needs to contact Microsoft? What is it doing/verifying? If I close the outgoing access to the Internet it is complaining "Couldn`t retrieve remote JWK set: connect timed out". So it looks like it is mandatory...
Could anybody explain how this is working? Beside this, does anybody know what range of ports need to be opened to microsoft?
Thanks in advance for your help!
Regards,
Peter
That network call is used to acquire the keys needed to verify the JSON Web Tokens.
Docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#validating-the-signature
More: https://github.com/microsoft/azure-spring-boot/issues/802#issuecomment-571076721
i have many application servers (cyber-ark, SIEM solution, forti gate etc') installed on azure as a IaaS.
all of them connect to an smtp server in order to send notifications via mail.
on my on Prem deployments, this was not an issue, but on azure, all smtp communication seems to be blocked.
i created a send-grid account and tried playing with it, but the send grid smtp server is getting blocked too.
what is the right way to work in this scenario ?
i need a smtp server to integrate with my applications...
what should i do ?
thanks,
david
Depends on your type of subscription, pay-as-you-go if you want the ability to send email from Azure VMs directly to external email providers (not using an authenticated SMTP relay), you can make a request to remove the restriction. Requests will be reviewed and approved at Microsoft's discretion, and they'll be granted only after additional anti-fraud checks are made. To make a request, open a support case by using the following issue type: Technical > Virtual Network > Connectivity > Cannot send email (SMTP/Port 25). Make sure that you add details about why your deployment has to send mail directly to mail providers instead of using an authenticated relay. More details
I am trying to get data into Azure Iot-Hub using a SARA-R410-02B module (NB-IoT) via MQTT or HTTPS. Microsofts MQTT guide for IoT-Hub states that:
For the Username field, use {iothubhostname}/{device_id}/?api-version=2018-06-30, where {iothubhostname} is the full CName of the IoT hub.
For example, if the name of your IoT hub is contoso.azure-devices.net and if the name of your device is MyDevice01, the full Username field should contain: contoso.azure-devices.net/MyDevice01/?api-version=2018-06-30
For the Password field, use a SAS token. The format of the SAS token is the same as for both the HTTPS and AMQP protocols:
SharedAccessSignature sig={signature-string}&se={expiry}&sr={URL-encoded-resourceURI}
This means that the username (and password) will exceed the 30-character limitation that i have on the SARA-R410. Is there any way around this? I have the same limitation when it comes to HTTPS.
I have found that the password limitation can be solved by using x.509 certificates, but the username remain the same.
If your device is capable of X.509 authentication then it will resolve your password issue but, as you note, it will not resolve your user identity problem. You might try it without the api parameter and see if it will assume a default. That would give you a few characters to play with if it worked.
Failing that, you would need to set up an application to receive the telemetry and forward it to the hub. Such as publish everything to a mosquito server and have an app subscribe to it and forward. Unfortunately adds more administration and points of failure.
I´ve tried without the api parameter for the HTTP, and it does not work. I have some problems with coverage, so i still haven't tried with MQTT, but I am guessing that the result will be the same?
I got an answer from u-blox. They say it can be worked around by implementing the MQTT protocol using sockets on the SARA-R410. This seems like the best solution.
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.