I have developed an integration using docusign SOAP API. We had the integration certified. It works great using the demo API URLs and my dev account. When I update the API URLs to production and use my live production account I get the return status of "One or both of Username and Password are invalid" when I call CreateEnvelope(). I have verified the user name and password are correct. I use them to log into the production account. I am setting the username in the code like [APIKEY]APIUSERNAME.
Does a DocuSign account need to be authorized to use an integration? How do I know my integrators key was moved over to production after certification? Any ideas when this works in dev but not in production.
Just wanted to follow up and post the answer to this issue. After working with Partner support I was able to get things working.
The issue was related to using the wrong base url when I created my api proxy. I was just passing in the docusign production url, when I actually needed to get this in the configuration for each user that uses the integration. When I get the base url in the config part of the app it return the actual server which the users account resided on (which includes the na1 or na2 etc server name in the url). After adding this to the config and using this new base url in my calls the app works as it should.
Yes I believe DocuSign production accounts need to be authorized to use the API. If you are positive that you are passing the correct username and password in your code then it's quite possible that this is an account issue.
For resolution I would suggest the following. For questions regarding your integration key and if it was indeed promoted to production following your successful certification you should contact
apicertifications#docusign.com
And if you have an account manager you might want to try reaching out to them as well, which might get your questions answered sooner.
Related
So I have been using docusign developer account for performing in-person and remote signing using docusign APIs. I am interesting in knowing 2 things:
The developer account (with the base url account-d.docusign.com) seems to be working fine for me. Why can't I use it for production as well. What difference/advantage does the paid account(with API access) has? What changes exactly when the integration app that I am using for docusigning goes live from "demo", other than the base url (i.e., account.docusign.com)?
When I login to my account, and go to Settings > Integrations > Apps & Keys, I can see a value "baseUrl" under "API Username" and "API Account ID", this value is either "https://na3.docusign.net" or "https://demo.docusign.net". However, when I use either of these values in my code to perform in-person or remote signing, it gives error. I have to use url account-d.docusign.com, then the API calls work correctly. What is the use of baseUrl mentioned in the portal then? Does it change when the integration app goes live? In our old app we just changed the url in code from account-d.docusign.com to just account.docusign.com when app went live and it worked.
Production accounts are the only ones you can use for "real" i.e. valid signatures for legal purposes. Developer account (demo) is for developing, testing, showing what can be done to customers etc. You need to follow the Go-Live process to enable your integration in production.
the baseURL is for API calls, not for authentication. And like you indicated, it's different in each env. If your code already handles this - you don't need to worry about it, but this is not the URL for the web app, rather the URL to make API calls.
I've built an API-based integration with DocuSign (using their PHP SDK), and am now at the point of deploying to the production server. I have reconfigured everything with the production integration key, public/private key pair, user and account IDs, endpoint URL, etc. replacing the demo ones. The OAuth portion of the conversation is working fine, and I get a valid token back. When I then try to send an envelope, I hit a USER_LACKS_MEMBERSHIP error, and cannot figure out why. As far as I can see, everything about the API user is the same between the demo and production systems.
I've authorized the application and made sure that it's in the list of "Applications with Access to DocuSign".
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Most of the documentation that I can find on this simply repeats the generic error text: "The UserID does not have a valid membership in this Account." If I go to the account admin and look at the list of users, the one I'm expecting is right there, with DS Admin permission; not sure what else might be done to give them "membership". One mentioned not using SendOnBehalfOf, but I'm not, so I can't really remove that.
All the code is identical, just configuration that's changed. Not sure where else to look. Anybody have any suggestions for what to try?
FURTHER INFORMATION
I've tried the getUserInfo call in the SDK, passing the same access token I use for the other call. It returns successfully, showing that it is for the user I'm expecting, in the one group we have, on the production server. And yet, when I enable logging again, as this same user, there is still zero record in the resulting logs of any of this API activity.
Attempts to do things like list templates with the SDK fail with the same USER_LACKS_MEMBERSHIP error.
Using the Diagnostics API (again, through the SDK) to check logging status shows that it is NOT enabled (despite my enabling it in the UI), but can be enabled with a separate call. Subsequently attempting to use listRequestLogs in the SDK generates a 404 error, though the URL matches what's listed in the API documentation (/v2/diagnostics/request_logs). Not sure whether these findings confirm that I'm somehow logging onto the API and the UI with different users (even though the user name and internal ID match), or that there's some problem with the logging facility in DocuSign.
The problem turns out to be the URL I was using for API calls. I switched from demo.docusign.net in testing to www.docusign.net in live, but being in Canada we need to use ca.docusign.net. For those who find this later, you can get the correct base path to use from the oauth/userinfo endpoint, or the getUserInfo() call through the SDK (PHP SDK, at least; don't know what the analogous call would be in others).
There are 3 things to consider:
API calls are made to an endpoint (URL) that contains the account # (either GUID or short form) in the url. Take a note of that number in the url.
Auth Token is a token for a specific user in a specific account.
UserId for the specific call. That is a specific user in the account.
If the user is not in the account, or there's a mismatch between #1 and #2 - you'll get this error. You must work with a single account and have it in all places as well as the user must be a member of this account.
Re:
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Since the request logging is not showing your API activity, the problem is that the person you've logged in as on the web tool is not the same as the person (user id) that you've logged in as on your application.
Solution for OAuth Authorization Code authentication: double check that when your app is logging into DocuSign, you're using the account.docusign.com authentication server, not the account-d.docusign.com auth server. (Look at the URL in your browser during the login sequence.)
Solution for OAuth JWT authentication: re-check that the impersonated user id is from the production system and you're using the right authentication server
I'm using the Docusign API with a nodejs server. I just recently promoted my sandbox integration key to production "live" and have updated my account ID, Client ID, etc so I hit the production account however, whenever I try to create an envelope, I get this error:
text: '{\r\n "errorCode": "USER_LACKS_MEMBERSHIP",\r\n "message": "The UserID does not have a valid membership in this Account."\r\n}',
I only have 1 user in the prod account so I'm not sure why this user would not have a valid membership. What's the best way to go about debugging this type of issue?
What I was missing here was that I wasn't setting the oauthpath correctly. I'm using the nodejs api and you should use apiClient.setOAuthBasePath() to set it.
If you don't set it, it will default to the demo url. Just in case this helps anyone else.
I am getting below error while accessing DocuSign SOAP service using SOAP UI tool. I also tried using integration key in username [Integration Key]userguid format I got same exception.
Can you please help me to resolve this issue.
Ok I've found out which option it is, and have enabled this option on your account. You should be able to export authoritative copies from this account now. For reference sake, the option I enabled was a member setting called
Can Export Authoritative Copies?
Please note, though, that since this is a setting that we have to enable on DocuSign's side, that means that it might be an enterprise or workgroup level feature. On your demo account we enable whatever you like so you can test things out, however when you are ready to move to production and purchase a corresponding production account that uses the API, you'll need to make sure you purchase an account that allows this feature. You can find out more from your Account Manager.
I have deployed Orchard on azure and enable Email Messaging module. Enabling says it enables successfully and asks for email settings. I provided it the mail server setting. Strange thing is, User setting does not show me the settings which are dependent on email messaging module (Contact us email address and public site name) and does not show me ("Lost your password") link . Also I have built a module which sends email. This module is not sending email.
Same orchard package works fine and also email on my dev server with same mail server settngs(gmail smtp settings.) But email is not working on azure.
What am i Missing ?
thanx
Just FYI for anyone else who visits this Question, I just got this working from Azure using the gmail SMTP server without any third party add-ons. I simply added the following SMTP details:
Then used the contact form to send an email to myself. The first email gives me an alert to my gmail account:
Hi Simon,
Someone recently tried to use an application to sign in to your Google Account - XXX#gmail.com.
We prevented the sign-in attempt in case this was a hijacker trying to access your account. Please review the details of the sign-in attempt:
Monday, April 8, 2013 9:33:46 PM UTC
IP Address: 65.52.168.70
Location: United States
...blah blah blah
If this was you, and you are having trouble accessing your account, complete the troubleshooting steps listed at http://support.google.com/mail?p=client_login
Following the link give you the option to allow an application to login with your credentials. Just follow the link in step 3 and then you have 10 minutes to send another email from your orchard site. The next test message I received without issue.
Got it. Windows Azure itself does not allow sending email neither it allows to use SMTP. WE have to use third party email service like PostMark,SendGrid etc
http://blogs.msdn.com/b/publicsector/archive/2011/10/14/sending-and-receiving-email-in-windows-azure.aspx
So, I'm just curious how does WordPress, installed on Windows Azure (gallery), able to send emails?
http://coffee2code.com/wp-plugins/configure-smtp/
There are still too many different suggestions on the subject so i thought i should write what I've found useful. Here's what i did to get it to work:
My SMTP settings:
Sender address: myname#gmail.com
Hostname: smtp#gmail.com
Port: 587 (25 will also do)
SSL Communications: Checked
Credentials: My Gmail address and my password
These settings should work on your local environment just fine. But on the cloud you may need to do the following:
As your Azure VM may be at some arbitrary location, Gmail marks the login attempts as suspicious and blocks them. If this is the case, you should see a mail informing you about this suspicious activity in your inbox. Just follow the instructions there and mark the login as trusted. It will remain that way until somehow your IP on the cloud changes (e.g. deleting your deployment slot). VM relocation shouldn't be an issue since the IP still remains the same. You may have to do this separately for your staging and production slots.
Lastly, I enabled full trust for my web role as shown here:
http://blogs.msdn.com/b/windowsazure/archive/2009/03/18/hosting-roles-under-net-full-trust.aspx
I hope this helps others having this problem.
Cheers
No more third-party with GitLab 15.5 (October 2022):
Deliver emails using Microsoft Graph API with client credentials flow
If you’ve enabled security defaults in Azure AD,
legacy authentication protocols for SMTP are blocked.
You can now configure your GitLab instance to deliver emails using
Microsoft Graph API
with OAuth 2.0 client credentials flow.
See Epic, Documentation and Merge Request.
The gitlab.rb would include:
gitlab_rails['microsoft_graph_mailer_enabled'] = true
# The unique identifier for the user. To use Microsoft Graph on behalf of the user.
gitlab_rails['microsoft_graph_mailer_user_id'] = "YOUR_USER_ID"
# The directory tenant the application plans to operate against, in GUID or domain-name format.
gitlab_rails['microsoft_graph_mailer_tenant'] = "YOUR_TENANT_ID"
# The application ID that's assigned to your app. You can find this information in the portal where you registered your app.
gitlab_rails['microsoft_graph_mailer_client_id'] = "YOUR_CLIENT_ID"
# The client secret that you generated for your app in the app registration portal.
gitlab_rails['microsoft_graph_mailer_client_secret'] = "YOUR_CLIENT_SECRET_ID"
gitlab_rails['microsoft_graph_mailer_azure_ad_endpoint'] = "https://login.microsoftonline.com"
gitlab_rails['microsoft_graph_mailer_graph_endpoint'] = "https://graph.microsoft.com"