Azure Communication Service rewriting email urls to azurecomm.net - azure

While sending emails using Azure Communication Services, the sent emails contain our company URLs which are rewritten to azurecomm.net URLs which is not expected behavior.
If we use a URL like, https://api.example.com/test it sends this exact URL but if we use a URL like, https://example.com, it's changing the URL to https://action.azurecomm.net/api/...
Would appreciate any help in the matter.

As explained in the comment by #rocky, rewrite automatically happens on <a href> as it's used by ACS to track user interaction on the email.
To toggle user tracking, you can go to Communication Service > go to Domains (under email section) > click on the domain name (second column) > in the overview section to the right there's an option to toggle User interaction tracking
Hope this helps someone.

Related

DocuSign Apps` Redirect URIs

We are trying to build a DocuSign integration (connector) to our application and is adding Redirect URIs to Apps for Authorization Code Grant.
Question:
What are the limit of Redirect URIs that can be added to both demo & production account respectively?
Is there a way to bulk import or mass add Redirect URIs to App?
There isn't a published limit but I just tried it out on my demo account and it let me add around 30-40 redirect URLs at least (the option isn't greyed out yet but I got tired of clicking). If you find that you hit the limit and would like the ability to add more redirect URIs, create a case with DocuSign Developer Support and we can discuss your use case.
You will need to add all redirect URLs manually, however.

DocuSign error "The redirect URI is not registered properly with DocuSign" with proper & valid redirect uri registered in application

We have docusign integrated in our platform & all of a sudden we are getting error from DocuSign
"The redirect URI is not registered properly with DocuSign".
We have proper & valid redirect uri configured in the application.
Please Note that exsisting setup is working fine, for newer apps or newer accounts, it is throwing the above-mentioned error Here is the screenshot of the same .
The redirect uri is valid as it's working for other app.
Has something changed at DocuSign end recently?
Update:
As asked, Please find the redirect uri screenshots below (I've masked the host url),
DocuSign Redirect URI configuration - Please note that both URI are same with difference in host url.
Complete Oauth request url
Redirect window
Make sure to compare the URL you see in the browser to the one in the IK. Make sure it's the same IK, in the same env (production vs. developer env is different!). Even a tiny difference between the two URLs will fail this. You need to URL decode the redirecUri from the main URL and then use that by copy/pasting it into the apps and keys page.
Then wait about 1-2 minutes before trying again.
Edit: confirmed that the URLs DO NOT MATCH, and that is the issue. The URLs must match 100% for this to work
Redirect URIs are specific to each integration key (application) and do not get copied over if you make a new integration key. Based on your description it sounds like you have created a new integration key. I would recommend visiting the Apps and Keys page on your DocuSign Admin settings and adding the redirect URI to the new integration key. Here is a support centre article which outlines this including the steps for how to add a new redirect URI
Nothing in this area has changed on DocuSign AFAIK.
Check that the redirect URI specified in your initial OAuth redirect is the exact same as the URI you set in the Integration Key's settings page.
The redirectURI cannot include any dynamic data including query parameters, etc.
You can use the settings tool's Apps and Keys page to delete and then re-add the RedirectURI. Check carefully that it doesn't include any trailing spaces, etc.
After you've made a change via the Apps and Keys pages, wait 5 minutes before attempting to use the Integration Key.
Ensure that you're using the right Apps and Keys page. If your app has passed go-live then:
For the production systems, use the apps and keys page from docusign.net
For the developer (demo) system, use the apps and keys page from demo.docusign.net

Is there a way to put authentication on calendar subscription url which is in ics format in outlook?

I have created a URL for subscribing to calendar events, mainly in Outlook. Since it has private information, I want users to be able to authenticate when subscribing to this calendar URL using a username and password. I don't want users to add passwords in the URL in order to authenticate.
Is there a way to achieve this where potentially a dialog box appears in outlook where user can enter their security credentials or some other way to authenticate? I'm using node.js on server side.
Thanks in advance!
I don't believe there is a consistent way to do this:
The RFC5545 specification is meant to "provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet".
Ie the receiving application must be able to access the url. It may work for some if the application user is able to access the url at the time they are logged in, then fail at other times. This is what annoyed me intensely with a school application. One could login & download an ics file and import it BUT could not subscribe to it. So whenever there were updates at a minimum each term, one had to login and re download & import.
Option:
You could have people login and get their unique obfuscated url. This is how google calendar does it. It is a 'private' but public url - anyone who gets sent that url can subscribe to it. Since even if it weren't public, the person who logs in, could also download it and send the file around, there is only 'some' additional minimal risk.
At any stage if people are no longer authorised to access the URL, then for their url you issue a 410, or issue empty ics file, or one with dummy events .
Calendar subscription are just HTTP resources, so did you try to protect your resource with Basic Authentication, e.g. by using something like https://www.npmjs.com/package/basic-auth ?

Customize URL landing page for Sign Complete for individual signers in routing

have a special thing we want to do. Hope you can help, we are using the standard web interface login and powerform templates enabled.
We have 3 different signers for our document
and we want each user to be re-directed to a different URL
User 1 -> URL A;
User 2 -> URL B;
User 3 -> URL C;
Are there any ways to accomplish this?
Right now I know there is a branding section in preferences where we can specificy viewed, complete, finish later, decline, etc. However upon completion of each step we wanted to specify the URL that user is sent to. This would remain the same for all docusigns we send out, this is not unique for each docusign transaction.
I do not believe this is possible using anything out of the box with DocuSign. The granularity to map different landing pages in DocuSign on a per recipient basis does not exist.
IMO to achieve such a behavior you would need a custom landing page with some business logic that will re-direct the user based off some parameter or information available on the URL. Again, this would be all custom built.

How to collect e-mail addresses from a click of a button?

My team and I are currently exploring different methods of collecting email addresses from our website visitors.
We want to do something cooler than a contact forms, and we really like the way quicksprout.com handles this and would like to do the same.
Where would I start to implement collecting email addresses through a couple clicks of a mouse via connecting our visitors through google plus api from our homepage? Is this possible to implement through a regular http static html site?
NO A server is needed in order to collect email addresses. At least in order to add them to a database. This can not be done using just a static html site.
Now, since a server will be needed, you can just access the emails like link (This also avoids a hassle with Same Origin Policy)
For example: Let the user login via google oauth, save the user related email in your database. fine
(if the user has saved its login data in its browser or is already logged into its google account in the used browser, this would be a mouse click only solution.)

Resources