Omówienie

Interfejs Document API dostępny w usłudze Adobe Sign zaprojektowano w celu bezproblemowej integracji z istniejącymi aplikacjami bez konieczności korzystania z osobnego procesu rejestracji zarządzanego przez usługę Adobe Sign. Dlatego też za sprawdzenie, czy nadawca jest zarejestrowanym użytkownikiem usługi Adobe Sign, odpowiada aplikacja korzystająca z API. Jeżeli nadawca nie został zarejestrowany, aplikacja rejestruje go automatycznie. Odbiorcy nie są proszeni o rejestrację, usługa Adobe Sign zarządza 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 Adobe Sign. 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. Usługa Adobe Sign 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 Adobe Sign, musi on zostać zlecony przez nadrzędnego użytkownika konta.

Zarządzanie kontem Adobe Sign

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

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

Tworzenie konta

Jeżeli wywołanie metody verifyUser wykaże, że użytkownik o podanym adresie e-mail nie istnieje, można programowo stworzyć konto usługi Adobe Sign, 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łudze Adobe Sign 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ługi Adobe Sign. 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