概述

设计 Document Cloud eSign 服务文档 API 的目的在于,您无需另外执行由 eSign 服务管理的注册流程,即可与现有应用程序无缝集成。为此,该内含应用程序将负责确保发送者是经过注册的 eSign 服务用户。如果发送者未经注册,则可以通过该 API 采用编程方式进行注册。对于接收者,系统从不要求他们必须注册,因为无论接收者是否有必要交互,eSign 服务始终都会进行管理。

指定一个文档发送者

使用 sendDocument 方法启动一项新事务时,指定发送者的方式可以有多种。具体的行为取决于通过可选的 SenderInfo 参数传递了哪些值。

  • SenderInfo 参数值为 Null:对于这种情况,文档的发送者是与将要使用的 API 密钥关联的特定且唯一的用户。这种方法适用于测试和实施具体的限定范围,但是通常并不适用于大规模集成现有的用户组。
  • SenderInfo 参数的值包含 emailpassword:对于这种情况,文档的发送者是 email 参数指定的用户。提供的密码必须与该用户的 EchoSign 密码相同。出于集成的目的,可以在要发送文档时,在内含应用程序的环境下征求该用户的电子邮件地址和密码。或者,内含应用程序可以记住电子邮件地址和密码,因为是该内含应用程序创建了该用户,或者是由于该用户此前已经提供了这项信息并且系统已进行了缓存。
  • SenderInfo 参数的值包含 email,且没有 password:对于这种情况,文档的发送者是 email 参数指定的用户。password 的值必须为 null。EchoSign 会验证 API 调用方与预期的发送者是否属于同一帐户,但是并不要求提供或检查密码。有时,这种方法适用于某一特定组织内的 API 集成,但是个人的安全性会因此而有所降低。这种身份验证模式必须由主帐户持有人发起显式请求,方可通过 EchoSign API 进行使用。

eSign 服务帐户管理

正如上文所述,大多数情况下,您希望提供发送文档的委托用户的电子邮件地址和密码。下面的内容概述了获取该信息的各种方法。

提示用户

提示用户输入其 eSign 服务电子邮件地址和密码,以此作为发送流程的一部分。可使用 verifyUser 方法来检查用户是否注册了 eSign 服务以及密码是否有效。如果用户尚未注册,您既可以要求他们创建自己的 eSign 服务帐户,也可以为他们创建一个帐户(请参见下方内容)。

创建帐户

如果调用 verifyUser 方法后系统显示不存在任何具有该电子邮件地址的用户,您可以采用编程方式通过调用 createUser 方法来创建一个 eSign 服务用户。假设成功创建了用户,那么您提供的电子邮件地址和密码现在就可以用作文档的 SenderInfo 内容。

记住帐户

在执行了上面所提供的任一方案后,接下来,您可以记住用户的电子邮件地址和密码,并代表该用户将这些信息用作发送后续文档的 SenderInfo。实际上,该用户可能会随时登录到他的 eSign 服务帐户并更改密码,因此您的应用程序必须能够处理“此前保存的密码无效”的情况。

总结

使用 eSign 服务文档 API 时,可以有多种方法确定发送者的身份。请仔细阅读上面的信息,确定适合您应用程序的具体方法。如果您有任何问题,请随时联系我们

本产品经 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License 许可  Twitter™ 与 Facebook 中的内容不在 Creative Commons 的条款约束之下。

法律声明   |   在线隐私策略