We have Docusign set up to use a customer's file number as the access key when they receive an envelope and they use their email/this key to do the signing.
We want to modify the Docusign email resource file to reword the footer info because the access code in the footer is not what the customer needs to enter for their signing ceremony and this is causing confusion. Docusign mentioned to us that if we modify this email resource file and later decide that are changes are no longer needed, that we can never go back to the standard email resource file. I can't understand why we can't go back to the standard file, it doesn't make sense. Has this happened to anyone else?
Uploading a Branding Resource File only modifies parameters that are changed, so it's technically correct that you can "never go back" to the actual default by uploading additional resource files. You can upload a version of the default that has the impacted parameters slightly modified, and that will overwrite your more extreme changes.
The simplest way to reset a brand entirely is to delete the brand and recreate it. Alternatively, you can export the brand, modify the resulting file and upload it again.
Related
Is it easy for people to find "public" google sheets/docs?
Context: Storing some semi-sensitive data (individual user info, of non-sensitive nature) for an app beta-test in google sheets. Planning to migrate to some DB in the future, but for now, just using JavaScript to pull the data directly from the google sheets (since there are visualizations being dynamically updated by the sheets).
Yes, it's easy to get information. Search engines may index and cache the information. Then, there are bots, crawlers and scrapers. Do NOT put (semi)sensitive information in public. Implement google-oauth properly with google-sheets-api to get information. You can also use service-accounts
Yes, it can be easily accessed.
According to the official Google article Share files from Google Drive: when you set your file's General Access setting to public:
Anyone can search on Google and get access to your file, without signing in to their Google account.
What you can do:
In the case of your app beta-test in google sheets data, you may want to reconsider to change your file's General Access setting to one of the following (in descending order of security):
Restricted - Only people that you manually give access to can view or edit your files. When you click the share button, a prompt will show and you may manually add the users who can view or edit your files:
Afterwards, you may select a role for those users and then they can be notified afterwards through email.
On the other hand, you can share the link to others. A prompt will show like the one below if you send the url through Google Chat:
You may opt to select Don't give access which will result in the following view on the other user's end:
This would mean that if unauthorized users get hold of the file URL, they will still need to send an access request. If other users submit the request, an email notification will be sent to your mail inbox. Other users who also own the file will also be notified by mail.
Your Organization - If you use a Google Account through work or school, anyone signed in to an account in your organization can open the file. If you are an administrator in a work or school workspace, you may set how members can share content within the organization. The administrator can prevent the sharing of content with group members outside your organization. If external sharing is prohibited, only group members who are in your organization can access the group's shared content.
Anyone with the link - Anyone who has the link can use your file, without signing in to their Google Account. This option is least recommended because if the URL is leaked to unauthorized users, they can easily access the file.
References:
Share files from Google Drive
Share content with a group
Don’t make it public unless you want the public to see it. Use oauth to access.
We are following Azure B2C sample code Azure AD B2C: Force password reset first logon to implement logic to force new local user to reset the password on the first login since we don't want them to use temporary password we generated for them. It has been working good for us, however recently one of such end users got this error "Missing required element [Email Address]" during reset screen:
.
We have been tried to reproduce this and we could not. We are not sure how to investigate this further at this point. Could someone shed some lights on this issue?
This kind of error is displayed when there is an issue with loading content definition properly declared in the custom policies. I faced similar issue in one of the projects where we used custom policies together with content (HTML, CSS) stored on the Azure Blob Storage.
When the name of a blob folder was called default, for some reason the presence of this word in the href tags of the html templates seems to cause the issue. When the folder name was changed to standard, it worked without issues.
Make sure that you have proper "load URI" declaration and check the folder name where you store HTML and CSS files.
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 ?
It appears that it is possible to generate an envelope using a template that does not belong to the account that was authenticated in the REST call. The two accounts were completely unrelated. Access to the generated envelope is limited to the account that generated the envelope; however the access to the template seems to be allowed to any account.
Scenario where this behavior was noticed:
- Account 1 - Created Template #1
- Account 2 - Generate an envelope using Template ID generated by Account 1
I could not find documentation or configuration related to behavior.
I need to confirm if the behavior is intended/supported before we plan to utilize the functionality.
Probably your best solution if you want to use Templates from one account in another is to simply move them. You might only be able to do this in the classic UI so you might have to switch back through your preferences, but you can:
Download the actual XML for each template you want to "share" across accounts.
Open the second account and select to upload template(s) and chose the XML files you downloaded.
As mentioned you might have to switch back to the classic UI to download/upload, but you definitely will not be able to use Templates from one account when you are an un-authenticated user in another account.
I uploaded a file DocuSign_EmailResources.xml to override the Master file and I do not my the changes. The documentation says that 'The ability to use the resource file option is not
normally enabled for an account; contact your Account Manager or DocuSign Support for more
information about enabling this option in your account'.
Before we update our production, we would like test on our demo account using SOAP API. I just want to add a link to the Email text. When I try this through the API, the link is disabled in the email as it is being formatted by the server side program.
Is there any setting that I am missing.
Thanks in advance.
If you can see (and access) the Resources tab when Editing a Brand Profile in the DocuSign web console, then this should mean that "the ability to use the resource file..." is indeed already enabled for your account.
The Email Resource file is quite lengthy, and is divided into various sections -- each section being the email template that's used for a specific type of email that DocuSign sends. So, for example, if you wanted to modify the contents of the "signing invitation" email that DocuSign sends to a recipient when it's their turn to sign, you'd modify contents within the Envelope Activation section of the Email Resource File. Changes applied to other sections of the resource file would not impact/affect the signing invitation email. If you haven't already done so, I'd suggest that you review the Email Resource File Guide (http://www.docusign.com/sites/default/files/DocuSign%20System%20Default%20Email%20Formats.pdf) to ensure that you've modified the correct section of the resource file for the type of email that you intend to effect.
Also, keep in mind that each Email Resource File applies to a specific (single) Brand. So, if you have multiple Brands within your account, make sure that you're modifying the Email Resource File for the Brand that's used for the Envelopes where you expect/want customized email content.