Udostępnianie danych logowania w żądaniach do interfejsu API zwiększa wydajność i pozwala uniknąć nadmiernego narzutu, który może skutkować błędami limitu liczby żądań. Z tego przewodnika dowiesz się, jak zoptymalizować zarządzanie danymi logowania OAuth2, aby aplikacja mogła efektywnie korzystać z interfejsu Google Ads API.
Strategia udostępniania danych logowania będzie zależała od tego, czy aplikacja jest wielowątkowa czy wieloprocesowa (lub rozproszona). Aplikacja, która jest jednocześnie wieloprocesowa i wielowątkowa w każdym procesie, powinna stosować obie te strategie. Strategie te można również dostosować do wielu kont Google Ads.
Wielowątkowa
Każda sesja lub użytkownik utworzony przez wątek powinien używać tego samego obiektu danych logowania. Odświeżanie tokena dostępu też musi być wykonywane synchronicznie, aby uniknąć wyścigu.
Nasze biblioteki klienta dbają o to, aby dane logowania były bezpiecznym wątkowym obiektem, który odświeża się synchronicznie po wygaśnięciu swojego tokena dostępu. Każda z naszych bibliotek klienta ma obiekt sesji (czyli użytkownika) z danymi uwierzytelniającymi, których używa przez cały okres użytkowania. Aby udostępnić dane logowania w wątkach, wystarczy utworzyć każdą sesję przy użyciu tych samych danych logowania. Na przykład w bibliotece klienta Java można utworzyć pojedynczy element Credential i udostępnić go we wszystkich sesjach.
Wieloprocesowe lub rozpowszechniane
W przypadku procesów wieloprocesowych lub rozproszonych musisz zachować dane logowania, zanim będzie można je udostępnić. Aby mieć pewność, że wiele procesów lub serwerów nie próbuje odświeżać danych logowania jednocześnie, co skutkuje nadmierną liczbą żądań odświeżania, należy przypisać odświeżanie do jednego procesu.
Na przykład osobne zadanie lub usługa może być odpowiedzialne za okresowe odświeżanie danych logowania i aktywne przekazywanie ich do magazynu danych udostępnianego przez pulę serwerów. Każdy serwer może następnie pobrać dane uwierzytelniające z magazynu danych podczas tworzenia żądania do interfejsu API.
Odśwież zadanie
Zadanie odświeżania nie powinno czekać z zainicjowaniem odświeżania do czasu wygaśnięcia bieżących danych logowania. Może to spowodować wyłączenie aplikacji z powodu braku ważnych danych logowania. Jeśli jednak token dostępu tych danych wygaśnie w trakcie przetwarzania żądania do interfejsu API, żądanie zostanie zrealizowane, a wyniki zostaną zwrócone.
Zalecamy śledzenie czasu ostatniego odświeżenia tokena dostępu i wymuszenie odświeżania, jeśli do wygaśnięcia pozostanie mniej niż 5 minut.
Jeśli nie wiesz, kiedy token dostępu został ostatnio odświeżony, możesz spróbować go odświeżyć, zakładając, że stracił już ważność. Jeśli token dostępu nie zbliża się do daty ważności, serwer zwraca ten sam token dostępu wraz z milisekundami pozostałymi do jego wygaśnięcia.
Magazyn danych
Możesz wykorzystać istniejący magazyn danych lub wdrożyć taki, który służy do udostępniania danych logowania między serwerami. Rozwiązania obejmują serwery buforujące, takie jak Memcached, Infinispan czy magazyny danych NoSQL, takie jak MongoDB.
Magazyn danych powinien być zoptymalizowany pod kątem szybkiego odczytu, ponieważ żądań odczytu będzie znacznie więcej niż zapisów. Dane logowania muszą być bezpieczne.
Podczas przechowywania danych logowania należy przechowywać obliczone wartości expiry_time (teraz + expires_in) i refresh_token obok access_token. Wartość expiry_time jest obliczana jako czas żądania odświeżenia access_token plus czas expires_in.
Pula serwerów
Przed wysłaniem żądania każdy serwer lub proces w puli pobiera z magazynu danych najnowsze dane logowania. Dane logowania będą prawidłowe, dopóki zadanie odświeżania działa prawidłowo. Jeśli jednak zadanie odświeżania lub magazyn danych się nie uda, powinien być dostępny mechanizm zastępczy.
Jeśli serwer lub proces nie może pobrać danych logowania z magazynu danych albo dane uwierzytelniające wygasły, serwer powinien odświeżyć swoje dane logowania, aby umożliwić aplikacji dalsze korzystanie z interfejsu API do czasu rozwiązania problemu.
Zarządzanie danymi logowania na wielu kontach
Dane logowania wygenerowane do konta menedżera Google Ads umożliwiają uzyskanie dostępu do wszystkich jego kont podrzędnych. W przypadku użytkowników z jedną hierarchią konta menedżera zwykle wystarczy wygenerować dane logowania do konta menedżera najwyższego poziomu, które będzie używane na wszystkich podrzędnych kontach Google Ads.
Jeśli aplikacja potrzebuje dostępu do kont Google Ads, które nie są ze sobą powiązane w żadnej hierarchii konta menedżera, musisz wygenerować i utrzymywać różne dane logowania dla różnych kont, np. dla każdego konta klienta Google Ads, do którego masz dostęp, lub dla każdego konta menedżera najwyższego poziomu w niezależnych hierarchii.
Możesz stosować te same strategie w przypadku aplikacji wielowątkowych lub wieloprocesowych / rozproszonych, ale z niewielkimi zmianami. Jeśli używasz współdzielonego magazynu danych, dane logowania muszą być indeksowane według identyfikatora konta customerId, aby mieć pewność, że dane logowania są powiązane z właściwym kontem.
Dodatkowo zadanie odświeżania powinno odświeżać wszystkie dane logowania. Jeśli połączysz się z nowym kontem, konieczne może być uruchomienie zadania odświeżania.
Natomiast w aplikacjach wielowątkowych należy udostępniać obiekt danych logowania tylko w wątkach działających na koncie, z którym powiązany jest obiekt danych logowania.