Omówienie

Interfejs Document API dostępny w usługach eSign w Document Cloud zaprojektowano w celu bezproblemowej integracji z istniejącymi aplikacjami bez konieczności korzystania z osobnego procesu rejestracji zarządzanego przez usługi eSign. Dlatego też za sprawdzenie, czy nadawca jest zarejestrowanym użytkownikiem usług eSign, odpowiada aplikacja korzystająca z API. Jeżeli nadawca nie został zarejestrowany, aplikacja rejestruje go automatycznie. Odbiorcy nie są proszeni o rejestrację, usługi eSign zarządzają wszelkimi wymaganymi czynnościami po stronie odbiorcy.

Określanie nadawcy dokumentu

Istnieje kilka sposobów określenia nadawcy podczas tworzenia nowej transakcji za pomocą metody sendDocument. Zachowanie metody zależy od wartości przekazywanych za pośrednictwem opcjonalnego parametru SenderInfo.

  • Brak wartości parametru SenderInfo: w tym przypadku nadawca dokumentu jest określonym, unikalnym użytkownikiem powiązanym z wykorzystywanym kluczem API. Metoda ta nadaje się do testów oraz implementacji o ograniczonym zakresie, ale nie jest ona przydatna w przypadku integracji na dużą skalę korzystającej z istniejącej bazy użytkowników.
  • SenderInfo z parametrem email i password (hasło): w tym przypadku nadawcą dokumentu jest użytkownik określony za pomocą parametru email. Podane hasło musi pokrywać się z hasłem użytkownika EchoSign. W przypadku integracji adres e-mail i hasło użytkownika można podać w ramach aplikacji korzystającej z API tuż przed wysłaniem dokumentu. Ewentualnie aplikacja korzystająca z API może zapamiętać adres e-mail i hasło, gdy aplikacja utworzyła użytkownika lub ponieważ użytkownik wcześniej podał te informacje i zostały one zachowane.
  • SenderInfo z parametrem email i bez hasła: w tym przypadku nadawcą dokumentu jest użytkownik określony za pomocą parametru email. Wartość hasła musi być pusta. EchoSign sprawdza, czy autor wywołania API oraz żądany nadawca należą do tego samego konta, ale nie wymaga sprawdzenia hasła. Metoda ta nadaje się czasem do integracji API w ramach firmy, ale powoduje zmniejszenie bezpieczeństwa poszczególnych użytkowników. Aby można było korzystać z tego modelu poświadczania za pośrednictwem API EchoSign, musi on zostać zlecony przez nadrzędnego użytkownika konta.

Zarządzanie kontem usług eSign

Jak opisano to powyżej, w większości przypadków konieczne jest podanie adresu e-mail i hasła użytkownika, w którego imieniu ma zostać wysłany dokument. Poniższa sekcja zawiera ogólny opis różnych sposobów pozyskiwania informacji użytkownika.

Monit do użytkownika

Monitu do użytkownika z prośbą o podanie jego adresu e-mail i hasła do usług eSign. Aby sprawdzić, czy użytkownik jest zarejestrowany w usługach eSign, można skorzystać z metody verifyUser. Jeżeli użytkownik nie jest zarejestrowany, można poprosić go o zarejestrowanie własnego konta w usługach eSign lub stworzyć dla niego konto (patrz poniżej).

Tworzenie konta

Jeżeli zapytanie metody verifyUser wykaże, że użytkownik o podanym adresie e-mail nie istnieje, można programowo stworzyć konto usług eSign, wywołując metodę createUser. Zakładając, że tworzenie użytkownika przebiegło pomyślnie, podany adres e-mail oraz hasło można wykorzystać w parametrze SenderInfo dla dokumentu.

Zapamiętywanie konta

Po skorzystaniu z jednego z powyższych sposobów można zapamiętać adres e-mail i hasło użytkownika i wykorzystywać je w parametrze SenderInfo do celów wysyłania kolejnych dokumentów w imieniu danego użytkownika. Możliwe jest, że użytkownik zaloguje się do swojego konta bezpośrednio w usługach eSign i zmieni hasło, dlatego też aplikacja musi być przygotowana na przypadek, gdy wcześniej zapisane hasło okaże się nieprawidłowe.

Podsumowanie

Istnieje wiele sposobów określenia tożsamości nadawcy podczas korzystania z Document API usług eSign. Zapoznaj się uważnie z powyższymi informacjami, aby zdecydować, która metoda jest najbardziej odpowiednia dla aplikacji. W razie pytań skontaktuj się z firmą Adobe.

Ta zawartość jest licencjonowana na warunkach licencji Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Posty z serwisów Twitter™ i Facebook nie są objęte licencją Creative Commons.

Informacje prawne   |   Zasady prywatności online