Docusignapi 默认配置是静态的。我必须创建一个支持多个客户端的web服务

这是我的情况。我需要为我们的客户创建一个web服务，用于让他们的客户签署文档。我们的每个客户都有自己的用户名和密码等。我们只是一个集成合作伙伴，为他们创建一个后端集成服务来发送签名请求。签名者将不会登录到DocuSign进行签名

我做了一个测试并发送了一份文件。但是，任何后续调用都会在下面的第二行失败，并出现一个错误，即密钥已经存在。显然，我必须能够更改每个请求的用户名/密码，因为我们支持多个客户端用户生成签名请求。如何避免Configuration.Default是静态的并导致此问题

string authHeader = "{\"Username\":\"" + usr + "\", \"Password\":\"" + pwd + "\", \"IntegratorKey\":\"" + integratorKey + "\"}";
Configuration.Default.AddDefaultHeader("X-DocuSign-Authentication", authHeader);

更新：

所以，我最终切换到OAuth代码授权认证（参见下面的代码示例）。但是，这种静态配置仍然是一个问题。每个请求很可能有一个不同的OAuth令牌与之关联。我已经生成了一个类，在每个请求中实例化该类，在其中创建新的ApicClient。但是，默认配置仍然存在，带有上一个请求的默认头。这是一个明显的问题。所有配方和文档都使用此configuration.default方法。似乎以前一定有人遇到过这种情况，必须有一种解决方法才能在没有此问题的情况下获得配置集。特别是在服务环境中，如果我做了一些棘手的事情，比如删除/重新读取/更新在实例之间共享的默认头，这可能会导致各种问题。我只是看不到解决这个问题的方法

CustomClass lib = new Lib();
//Inside lib this is called before creating envelopes, etc.
ApiClient dsClient = new ApiClient(userInfo.Docusign_Rooturl); // userInfo.Docusign_BaseUrl);
DocuSign.eSign.Client.Configuration.Default.ApiClient = dsClient;
//This is the problem bit
    DocuSign.eSign.Client.Configuration.Default.AddDefaultHeader("Authorization",<oauth_token>);
return dsClient;

CustomClass-lib=new-lib（）；
//在lib内部，在创建封套等之前调用该函数。
ApiClient dsClient=新的ApiClient（userInfo.Docusign_Rooturl）；//userInfo.Docusign_BaseUrl）；
DocuSign.eSign.Client.Configuration.Default.ApiClient=dsClient；
//这就是问题所在
DocuSign.eSign.Client.Configuration.Default.AddDefaultHeader（“授权”）；
返回dsClient；

更新2： 我相信我成功地解决了这个问题。初始化ApiClient时，我使用以下代码，而不是使用默认配置对象：

 ApiClient dsClient = new ApiClient(<rootUrl>); 
        DocuSign.eSign.Client.Configuration config = new DocuSign.eSign.Client.Configuration(dsClient);
        config.AddDefaultHeader("Authorization", <oAuthToken>);
        dsClient.Configuration = config;
 EnvelopesApi api = new EnvelopesApi(dsClient.Configuration)

ApiClient dsClient=new ApiClient（）；
DocuSign.eSign.Client.Configuration config=new DocuSign.eSign.Client.Configuration（dsClient）；
config.AddDefaultHeader（“授权”）；
dsClient.Configuration=config；
EnvelopesApi=新的EnvelopesApi（dsClient.Configuration）

---

我希望这能帮助遇到同样问题的其他人。

要通过应用程序验证用户，您应该使用o

你可以了解更多

X-DocuSign-Authentication标题用于后端服务集成，其中没有最终用户参与

---

你也可以使用

最初设计用于代表帐户中的其他用户发送信封，代表发送（SOBO）是一种身份验证方法，允许用户（身份验证用户）以同一帐户中另一用户（操作用户）的名义发送信封并执行几乎任何任务

您可以在标头中指定sendOnBehalfOf值

 <DocuSignCredentials>
     <Username>nat.irving@example.com</Username>
      <Password>S3cre+p455w0Rd</Password>
       <IntegratorKey>230546a7-9c55-40ad-8fbf-af205d5494ad</IntegratorKey>
     <SendOnBehalfOf>ruggiero.gardener@example.com</SendOnBehalfOf>
   </DocuSignCredentials>

纳特。irving@example.com
S3cre+p455w0Rd
230546a7-9c55-40ad-8fbf-af205d5494ad
鲁杰罗。gardener@example.com

这是一个后端服务集成。用户名和密码是发件人的用户名和密码，每个签名请求的用户名和密码可能不同，需要在每次呼叫的标题中设置。对于使用静态对象的配置，如OP中所述，存在问题。没有最终用户通过DocuSign进行身份验证，我们正在对他们进行身份验证。我需要的是一种方法，在每次调用时设置带有用户名、密码和集成器密钥的标头（如果必要），这在sdk中似乎有问题。或者，当我已经拥有发件人的帐户ID和基本URL，并且在创建信封之前不需要进行身份验证时，生成签名请求的示例。我的理解是，SOBO将派人去找同一组织中的另一个人。这不是我们用例中发生的事情。下面是我们的工作流程，DocuSign说它是受支持的：1）我们的客户有自己的DocuSign帐户。2） 他们需要向没有DS帐户的客户发送用于签名的文档。3） 我们正在编写一个应用程序将调用的web服务。我们正在提供一个集成。4） 我们调用API传递他们的用户/pwd/acct Id/baseurl等，并调用我们的集成商密钥来获取签名uri 5）他们从他们的帐户获得自定义品牌，从您提到的链接“平台查找操作用户的电子邮件或用户Id，以确保它是身份验证用户帐户的成员。”这肯定行不通，因为他们不是为了我们，他们每个人都有自己的。我遇到的问题很简单，SDK会自动为请求重新使用相同的头，因为它是静态的。这对于web服务来说是不可行的。我只是在寻找一种绕过配置的方法。*Default*.AddDefaultHeader，以便每个调用都使用自己的配置值。否则我想我会跳过SDK直接调用。你想完成的事情不应该完成。您的应用不应具有访问用户凭据的权限。只有用户应持有其凭据并直接将其提交给docusign进行身份验证。这就是oAuth的全部要点。