Uwierzytelnianie i autoryzacja w protokole danych Google

Ostrzeżenie: ta strona dotyczy starszych interfejsów API Google, czyli interfejsów Google Data API. Jest ona istotna tylko w przypadku interfejsów API wymienionych w katalogu interfejsów Google Data API, z których wiele zostało zastąpionych nowszymi interfejsami API. Informacje o konkretnym nowym interfejsie API znajdziesz w jego dokumentacji. Informacje o autoryzowaniu żądań za pomocą nowszego interfejsu API znajdziesz w artykule Uwierzytelnianie i autoryzacja kont Google.

Aplikacje innych firm często wymagają ograniczonego dostępu do konta Google użytkownika w przypadku niektórych rodzajów aktywności. Aby zapobiec nadużywaniu danych użytkowników, wszystkie prośby o dostęp muszą być zatwierdzane przez właściciela konta. Kontrola dostępu składa się z 2 komponentów: uwierzytelniania i autoryzacji.

Usługi uwierzytelniania umożliwiają użytkownikom logowanie się w aplikacji za pomocą konta Google.

Usługi autoryzacji umożliwiają użytkownikom przyznanie aplikacji dostępu do danych przechowywanych w aplikacjach Google. Google poważnie traktuje prywatność, dlatego każda aplikacja, która wymaga dostępu do danych użytkownika, musi uzyskać jego autoryzację.

Usługi uwierzytelniania i autoryzacji są często określane łącznie jako uwierzytelnianie.

Uwierzytelnianie i autoryzacja w interfejsach API Google umożliwiają aplikacjom innych firm uzyskanie ograniczonego dostępu do konta Google użytkownika w przypadku określonych rodzajów działań. W tym dokumencie przedstawiamy dostępne mechanizmy uwierzytelniania i opisujemy, co każdy z nich zapewnia Twojej aplikacji.

  • Zaloguj się przez Google to prosty sposób na umożliwienie użytkownikom logowania się w Twojej witrynie za pomocą danych logowania do Google. Zawiera zestaw narzędzi, które można łatwo zintegrować z różnymi urządzeniami.
  • OAuth 2.0 to protokół autoryzacji dla wszystkich interfejsów API Google. OAuth 2.0 opiera się na protokole SSL, a nie na bezpośrednim podpisywaniu kryptograficznym przez aplikację. Ten protokół umożliwia aplikacji żądanie dostępu do danych powiązanych z kontem Google użytkownika.
  • Logowanie przy użyciu OAuth 2.0 (OpenID Connect) uwierzytelnia użytkowników, którzy logują się za pomocą swoich kont Google. Jest to zamiennik OpenID, więc użytkownicy OpenID powinni zaplanować migrację do logowania za pomocą OAuth 2.0.

Jeśli Twoja aplikacja jest gadżetem (do użycia w iGoogle lub innych kontenerach OpenSocial), zapoznaj się z sekcją Uwierzytelnianie w przypadku gadżetów.

Uwaga: ten dokument zawiera omówienie każdej metody uwierzytelniania. Szczegółowe informacje o poszczególnych metodach znajdziesz w pełnej dokumentacji interfejsów API uwierzytelniania konta Google.

Więcej informacji o korzystaniu z interfejsów Google Accounts API znajdziesz w grupie interfejsów Google Accounts API.

OAuth – autoryzacja aplikacji internetowych i zainstalowanych

Wiele usług Google umożliwia dostęp do danych generowanych przez użytkowników, takich jak dane z Kalendarza czy Dokumentów, pod warunkiem że użytkownik zezwoli na taki dostęp. Ta funkcja umożliwia użytkownikom udostępnianie i wymienianie danych między aplikacjami Google a aplikacjami innych firm w różnych celach.

Google obsługuje 2 wersje protokołu OAuth, które umożliwiają uzyskanie autoryzowanego dostępu do danych użytkownika w Google: OAuth 1.0 i OAuth 2.0. Obie wersje zapewniają dostęp do aplikacji internetowych i zainstalowanych.

OAuth 2.0 w przypadku aplikacji internetowych i zainstalowanych

Aplikacje internetowe i zainstalowane mogą używać nowego, uproszczonego protokołu OAuth 2.0 do autoryzowania dostępu do danych powiązanych z kontem Google. Szczegółowe informacje i przykłady implementacji protokołu OAuth 2.0 w Google znajdziesz w naszej dokumentacji na temat protokołu OAuth 2.0.

OAuth 1.0 w przypadku aplikacji internetowych

Aplikacje internetowe, które potrzebują autoryzowanego dostępu do danych powiązanych z kontem Google lub kontem Google Apps, mogą korzystać z implementacji interfejsu OAuth API od Google. Pełne informacje o wdrażaniu OAuth w aplikacjach internetowych, w tym przykłady, znajdziesz w przewodniku OAuth w aplikacjach internetowych lub w omówieniu w tym dokumencie.

OAuth 1.0 w przypadku zainstalowanych aplikacji

Aplikacje zainstalowane na komputerach i urządzeniach mobilnych użytkowników mogą używać OAuth do autoryzowania dostępu do danych powiązanych z kontem Google. Pełne informacje o wdrażaniu protokołu OAuth w przypadku zainstalowanych aplikacji znajdziesz w przewodniku OAuth dla zainstalowanych aplikacji lub w omówieniu w tym dokumencie.

Korzystanie z OAuth w aplikacjach internetowych

Wszystkie interfejsy Google Data API obsługują OAuth, otwarty standard autoryzacji używania danych w aplikacjach internetowych. Wszystkie aplikacje internetowe, które wysyłają żądania OAuth, muszą przesłać certyfikat zabezpieczeń i zarejestrować się w Google. Więcej informacji znajdziesz w artykule Rejestracja aplikacji internetowych.

Biblioteki klienta interfejsów API danych Google udostępniają metody, które pomagają korzystać z OAuth w aplikacji internetowej. W szczególności istnieją metody tworzenia tokena żądania, autoryzowania tokena żądania i wymiany autoryzowanego tokena żądania na token dostępu. Biblioteki te obsługują też niezbędne algorytmy podpisywania podczas wysyłania żądań do usługi Google Data. Szczegółowe przykłady używania OAuth z bibliotekami klienta interfejsów API danych Google znajdziesz w artykule Używanie OAuth z bibliotekami klienta interfejsów API danych Google.

Proces autoryzacji OAuth

Proces autoryzacji OAuth obejmuje serię interakcji między aplikacją internetową, serwerami autoryzacji Google i użytkownikiem.

Podstawowy proces wygląda tak:

  1. Twoja aplikacja prosi o dostęp i otrzymuje z serwera autoryzacji Google nieautoryzowany token żądania.
  2. Google prosi użytkownika o przyznanie Ci dostępu do wymaganych danych.
  3. Aplikacja otrzymuje autoryzowany token żądania z serwera autoryzacji.
  4. Wymieniasz autoryzowany token żądania na token dostępu.
  5. Tokena dostępu używasz do wysyłania żądań danych do serwerów dostępu do usług Google.

Gdy Twoja aplikacja po raz pierwszy poprosi o dostęp do danych użytkownika, Google wyśle do niej token nieautoryzowanego żądania.

Jeśli użytkownik nie jest jeszcze zalogowany, Google wyświetli prośbę o zalogowanie się. Google wyświetla wtedy stronę autoryzacji, na której użytkownik może zobaczyć, do jakich danych usługi Google aplikacja prosi o dostęp.

Jeśli użytkownik zatwierdzi prośbę aplikacji o dostęp, Google wyda autoryzowany token żądania. Każdy token żądania jest ważny tylko przez godzinę. Tylko autoryzowany token żądania może zostać wymieniony na token dostępu. Wymiana może być przeprowadzona tylko raz na autoryzowany token żądania.

Domyślnie tokeny dostępu mają długi okres ważności. Każdy token dostępu jest powiązany z kontem użytkownika określonym w pierwotnym żądaniu autoryzacji i przyznaje dostęp tylko do usług określonych w tym żądaniu. Aplikacja powinna bezpiecznie przechowywać token dostępu, ponieważ jest on wymagany w przypadku każdego dostępu do danych użytkownika.

Przygotowanie do OAuth

Zanim skonfigurujesz aplikację do korzystania z usługi autoryzacji Google z OAuth, musisz wykonać te czynności.

Decydowanie, czy zarejestrować aplikację internetową

Aby zapewnić użytkownikom dodatkowe gwarancje bezpieczeństwa ich danych, możesz zarejestrować aplikację internetową w Google i podpisywać żądania zarejestrowanym certyfikatem bezpieczeństwa. Niektóre kanały Google Data API są dostępne tylko dla zarejestrowanych aplikacji. Zapoznaj się z dokumentacją interfejsu Google Data API, który Cię interesuje, aby sprawdzić, czy działa on tylko w przypadku zarejestrowanych aplikacji.

Twoja aplikacja musi podpisywać każde wysyłane żądanie OAuth. Jeśli zdecydujesz się użyć podpisu RSA-SHA1 do podpisywania żądań, musisz przesłać certyfikat bezpieczeństwa w ramach procesu rejestracji.

Możesz też podpisywać żądania za pomocą podpisu HMAC-SHA1. W przypadku podpisów HMAC-SHA1 nie jest wymagany certyfikat. Zamiast tego Google generuje wartość OAuth consumer secret, która jest wyświetlana na stronie rejestracji domeny po jej zarejestrowaniu.

Więcej informacji o procesie rejestracji znajdziesz w artykule Rejestracja aplikacji internetowych.

Określanie zakresu danych, do których aplikacja będzie mieć dostęp

Każda usługa Google określa limity dostępu, który umożliwia za pomocą interfejsów Google Data API. Ten dostęp jest wyrażony jako wartość zakresu. Niektóre usługi udostępniają różne wartości zakresu, aby umożliwić użytkownikowi wybór aplikacji, które powinny mieć dostęp do określonych danych. Informacje o dostępnych wartościach zakresu dla usługi Google, do której chcesz uzyskać dostęp, znajdziesz w dokumentacji tej usługi.

Zwykle należy prosić o token w najwęższym zakresie, który obejmuje potrzebne dane. Jeśli na przykład Twoja aplikacja wymaga dostępu do pliku danych „Wszystkie kalendarze” użytkownika, powinna poprosić o token w zakresie http://www.google.com/calendar/feeds/default/allcalendars/full.

Konfigurowanie mechanizmu zarządzania tokenami OAuth

Gdy uzyskasz token dostępu OAuth do danych użytkownika, musisz go używać we wszystkich przyszłych interakcjach z określoną usługą Google w imieniu użytkownika.

Aplikacja powinna bezpiecznie zarządzać przechowywaniem tokenów, w tym śledzić usługę Google, dla której każdy token jest ważny. Jeśli potrzebujesz dostępu do więcej niż 1 usługi Google, możesz uzyskać kilka tokenów dostępu, ale w danym momencie nie może być aktywnych więcej niż 10 tokenów dostępu na użytkownika i aplikację.

Jeśli Twoja aplikacja obsługuje wiele kont użytkowników, musisz śledzić, z którym kontem jest powiązany każdy token. Każdy token OAuth jest przypisany do użytkownika, który autoryzował dostęp. Aplikacja musi mieć możliwość powiązania tokena z odpowiednim użytkownikiem. Jednym ze sposobów zarządzania tym procesem jest wydanie użytkownikowi pliku cookie przed wysłaniem żądania tokena. Gdy użytkownik przyzna dostęp do żądanych danych, Google wyśle autoryzowany token żądania i przekieruje użytkownika do Twojej aplikacji. Następnie możesz użyć pliku cookie aplikacji, aby powiązać token z odpowiednim użytkownikiem.

skonfigurowanie mechanizmu żądania dostępu do usługi Google;

Każde żądanie wysyłane do usługi Google musi być podpisane i zawierać prawidłowy token dostępu OAuth. Zazwyczaj każde żądanie jest wysyłane w formie żądania HTTP GET, a token dostępu i podpis są umieszczane w nagłówku. Żądania zapisujące nowe dane powinny używać HTTP POST.

Więcej informacji o prawidłowym formacie żądania dla każdego interfejsu Google Data API znajdziesz w dokumentacji tego interfejsu.

Wdrażanie OpenID (opcjonalnie)

Jeśli wdrażasz OpenID do uwierzytelniania użytkowników, rozważ użycie protokołu hybrydowego, aby połączyć te dwa procesy. W przypadku OpenID+OAuth zadania związane z uzyskiwaniem tokena żądania i jego autoryzacją są obsługiwane w ramach żądania OpenID z rozszerzeniami OAuth. Podobnie jak w przypadku OAuthGetRequestToken, te rozszerzenia służą do identyfikowania usług Google, do których ma być uzyskiwany dostęp. Odpowiedź świadcząca o powodzeniu wykonania żądania OpenID zawiera autoryzowany token żądania. Po otrzymaniu tego tokena użyj OAuthGetAccessToken, aby wymienić go na token dostępu.

Praca z tokenami OAuth

Aby używać OAuth, aplikacja musi generować prawidłowo sformułowane, podpisane wywołania żądań tokenów i obsługiwać odpowiedzi w przypadku tej sekwencji:

  1. Uzyskiwanie nieautoryzowanego tokena żądania (OAuthGetRequestToken)
  2. Autoryzowanie tokena żądania (OAuthAuthorizeToken)
  3. Wymiana autoryzowanego tokena żądania na token dostępu (OAuthGetAccessToken)

Wszystkie żądania OAuth muszą być podpisane, niezależnie od tego, czy aplikacja jest zarejestrowana. Więcej informacji znajdziesz w artykule Podpisywanie żądań OAuth.

Możesz eksperymentować z wysyłaniem próśb o tokeny autoryzacji i ich odbieraniem w OAuth Playground.

Szczegółową dokumentację znajdziesz w materiałach referencyjnych interfejsu API OAuth.

Ustawianie adresu URL wywołania zwrotnego

W żądaniu OAuthGetRequestToken możesz podać wartość parametru oauth_callback, aby określić, dokąd Google przekieruje użytkownika po tym, jak autoryzuje on Twoją prośbę o dostęp. Adres URL wywołania zwrotnego może zawierać parametry zapytania. Przekierowanie będzie zawierać te same parametry zapytania, a także token autoryzowanego żądania, który aplikacja musi być w stanie przeanalizować.

Jeśli na przykład obsługujesz wiele języków, możesz dodać parametr zapytania, który identyfikuje wersję aplikacji wyświetlaną przez użytkownika. Wartość oauth_callback „http://www.yoursite.com/Retrievetoken?Lang=de” spowoduje przekierowanie „http://www.yoursite.com/Retrievetoken?Lang=de&oauth_token=DQAADKEDE”. Analiza tokena i parametru języka zapewnia przekierowanie użytkownika z powrotem do właściwej wersji witryny.

Jeśli parametr oauth_callback nie zostanie uwzględniony, po autoryzacji Twojej prośby o dostęp Google przekieruje użytkownika na stronę internetową, na której wyświetlany jest numer weryfikacyjny (przykład). Zanim uzyskasz token autoryzacji żądania, użytkownik musi ręcznie wrócić do Twojej aplikacji i wpisać numer weryfikacyjny.

Identyfikowanie aplikacji dla użytkowników

Google zwykle wyświetla nazwę aplikacji, gdy prosi użytkownika o zgodę na dostęp (zobacz przykład).

Jeśli Twoja aplikacja nie jest zarejestrowana, użyj parametru xoauth_displayname w żądaniu OAuthGetRequestToken, aby podać nazwę aplikacji. Jeśli ten parametr nie zostanie określony, Google wyświetli nazwę domeny adresu URL podanego przez parametr oauth_callback. Jeśli nie podasz adresu URL wywołania zwrotnego, Google wyświetli ciąg znaków „anonymous”.

Nie ustawiaj tego parametru, jeśli Twoja aplikacja jest zarejestrowana. Domyślnie Google wyświetla nazwę wyświetlaną podaną podczas rejestracji. Jeśli w OAuthGetRequestTokenprośbie podasz nazwę wyświetlaną, Google użyje jej zamiast zarejestrowanej nazwy wyświetlanej i wyświetli komunikat o tym, że nie można zweryfikować tożsamości aplikacji.

Uwaga: aby ustawić parametr xoauth_displayname w OAuth Playground, przed pobraniem tokena żądania zaznacz pole „Zaawansowane”.

Praca z domenami Google Apps

Jeśli Twoja aplikacja jest przeznaczona dla użytkowników domeny hostowanych kont Google, podczas autoryzacji tokena użyj parametru hd. Więcej informacji o parametrze hd znajdziesz w artykule Obsługa użytkowników z wieloma kontami.

Więcej informacji o OAuth

Szczegółowe informacje o wdrożeniu protokołu OAuth przez Google, w tym o rejestrowaniu aplikacji i tworzeniu niezbędnych parametrów OAuth, znajdziesz w tych dodatkowych materiałach:

Powrót do góry

Korzystanie z OAuth w przypadku zainstalowanych aplikacji

Wszystkie interfejsy Google Data API obsługują OAuth, otwarty standard autoryzacji używania danych w aplikacjach. Aby korzystać z OAuth, zainstalowane aplikacje nie muszą być zarejestrowane w Google.

Proces autoryzacji OAuth

Proces autoryzacji OAuth obejmuje serię interakcji między Twoją aplikacją, serwerami autoryzacji Google i użytkownikiem.

Podstawowy proces wygląda tak:

  1. Twoja aplikacja prosi o dostęp i otrzymuje z serwera autoryzacji Google nieautoryzowany token żądania.
  2. Google prosi użytkownika o przyznanie Ci dostępu do wymaganych danych.
  3. Aplikacja otrzymuje autoryzowany token żądania z serwera autoryzacji.
  4. Wymieniasz autoryzowany token żądania na token dostępu.
  5. Tokena dostępu używasz do wysyłania żądań danych do serwerów dostępu do usług Google.

Gdy Twoja aplikacja po raz pierwszy poprosi o dostęp do danych użytkownika, Google wyśle do niej token nieautoryzowanego żądania.

Jeśli użytkownik nie jest jeszcze zalogowany, Google wyświetli prośbę o zalogowanie się. Google wyświetla wtedy stronę autoryzacji, na której użytkownik może zobaczyć, do jakich danych usługi Google aplikacja prosi o dostęp.

Jeśli użytkownik zatwierdzi prośbę aplikacji o dostęp, Google wyda autoryzowany token żądania. Każdy token żądania jest ważny tylko przez godzinę. Tylko autoryzowany token żądania może zostać wymieniony na token dostępu. Wymiana może być przeprowadzona tylko raz na autoryzowany token żądania.

OAuth obsługuje zainstalowane aplikacje w trybie niezarejestrowanym. Istnieją różne metody uzyskiwania autoryzowanego tokena żądania, więc aplikacja może używać OAuth do autoryzowania aplikacji nawet wtedy, gdy urządzenie, na którym jest zainstalowana, nie ma przeglądarki internetowej.

Domyślnie tokeny dostępu mają długi okres ważności. Każdy token dostępu jest powiązany z kontem użytkownika określonym w pierwotnym żądaniu autoryzacji i przyznaje dostęp tylko do usług określonych w tym żądaniu. Aplikacja powinna bezpiecznie przechowywać token dostępu, ponieważ jest on wymagany w przypadku każdego dostępu do danych użytkownika.

Przygotowanie do OAuth

Zanim skonfigurujesz aplikację do korzystania z usługi autoryzacji Google z OAuth, musisz wykonać te czynności.

Określanie zakresu danych, do których aplikacja będzie mieć dostęp

Każda usługa Google określa limity dostępu, który umożliwia za pomocą interfejsów Google Data API. Ten dostęp jest wyrażony jako wartość zakresu. Niektóre usługi udostępniają różne wartości zakresu, aby umożliwić użytkownikowi wybór aplikacji, które powinny mieć dostęp do określonych danych. Informacje o dostępnych wartościach zakresu dla usługi Google, do której chcesz uzyskać dostęp, znajdziesz w dokumentacji tej usługi.

Zwykle należy prosić o token w najwęższym zakresie, który obejmuje potrzebne dane. Jeśli na przykład Twoja aplikacja wymaga dostępu do pliku danych „Wszystkie kalendarze” użytkownika, powinna poprosić o token w zakresie http://www.google.com/calendar/feeds/default/allcalendars/full.

Konfigurowanie mechanizmu zarządzania tokenami OAuth

Gdy uzyskasz token dostępu OAuth do danych użytkownika, musisz go używać we wszystkich przyszłych interakcjach z określoną usługą Google w imieniu użytkownika.

Aplikacja powinna bezpiecznie zarządzać przechowywaniem tokenów, w tym śledzić usługę Google, dla której każdy token jest ważny.

Jeśli Twoja aplikacja obsługuje wiele kont użytkowników, musisz śledzić, z którym kontem jest powiązany każdy token.

skonfigurowanie mechanizmu żądania dostępu do usługi Google;

Każde żądanie wysyłane do usługi Google musi być podpisane i zawierać prawidłowy token dostępu OAuth. Zazwyczaj każde żądanie jest wysyłane w formie żądania HTTP GET, a token dostępu i podpis są umieszczane w nagłówku. Żądania zapisujące nowe dane powinny używać HTTP POST.

Więcej informacji o prawidłowym formacie żądania dla każdego interfejsu Google Data API znajdziesz w dokumentacji tego interfejsu.

Praca z tokenami OAuth

Aby używać OAuth, aplikacja musi generować prawidłowo sformułowane, podpisane wywołania żądań tokenów i obsługiwać odpowiedzi w przypadku tej sekwencji:

  1. Uzyskiwanie nieautoryzowanego tokena żądania (OAuthGetRequestToken)
  2. Autoryzowanie tokena żądania (OAuthAuthorizeToken)
  3. Wymiana autoryzowanego tokena żądania na token dostępu (OAuthGetAccessToken)

Wszystkie żądania OAuth muszą być podpisane, niezależnie od tego, czy aplikacja jest zarejestrowana. Więcej informacji znajdziesz w artykule Podpisywanie żądań OAuth. Zainstalowane aplikacje powinny postępować zgodnie z instrukcjami dotyczącymi aplikacji niezarejestrowanej.

Możesz eksperymentować z wysyłaniem próśb o tokeny autoryzacji i ich odbieraniem w OAuth Playground.

Szczegółową dokumentację znajdziesz w materiałach referencyjnych interfejsu API OAuth.

Identyfikowanie aplikacji dla użytkowników

Google zwykle wyświetla nazwę aplikacji, gdy prosi użytkownika o zgodę na dostęp (zobacz przykład).

Użyj parametru xoauth_displayname w żądaniu OAuthGetRequestToken, aby określić nazwę aplikacji. Jeśli ten parametr nie zostanie określony, Google wyświetli nazwę domeny adresu URL podanego przez parametr oauth_callback. Jeśli nie podasz adresu URL wywołania zwrotnego, Google wyświetli ciąg znaków „anonymous”.

Uwaga: aby ustawić parametr xoauth_displayname w OAuth Playground, przed pobraniem tokena żądania zaznacz pole „Zaawansowane”.

Uruchamianie przeglądarki

W ramach procesu autoryzacji OAuth Twoja aplikacja musi wysłać żądanie OAuthAuthorizeToken. Użytkownik musi następnie zalogować się na stronie internetowej Google i autoryzować prośbę aplikacji o dostęp.

  • W większości aplikacji należy używać trybu AutoDetect.
  • Tryb urządzenia powinien być używany w przypadku aplikacji, które nie mogą uruchomić pełnej przeglądarki internetowej.
  • Tryb deweloperski należy stosować tylko na wczesnym etapie programowania.

Tryb automatycznego wykrywania

Jeśli to możliwe, aplikacja powinna otworzyć okno przeglądarki i wysłać żądanie OAuthAuthorizeToken, aby otworzyć stronę Google. Gdy Google zwróci autoryzowany token, aplikacja powinna to wykryć i odzyskać fokus z przeglądarki.

Ten tryb wymaga podania adresu URL wywołania zwrotnego, na który użytkownik jest przekierowywany po autoryzacji żądania dostępu. Ten adres URL musi być podany jako parametr oauth_callback żądania OAuthGetRequestToken oraz jako parametr verifier żądania OAuthGetAccessToken.

Aby zwiększyć wygodę użytkowników, aplikacja powinna automatycznie wykrywać, kiedy użytkownik jest przekierowywany na ten adres URL, i natychmiast przechodzić na pierwszy plan oraz wysyłać żądanie OAuthGetAccessToken, aby zakończyć proces OAuth.

Więcej informacji i sprawdzone metody znajdziesz w artykule Automatyczne wykrywanie zatwierdzenia.

Jeśli aplikacja nie może automatycznie wykryć, kiedy użytkownik zostanie przekierowany na adres URL wywołania zwrotnego, ani nie może przejść na pierwszy plan, adres URL wywołania zwrotnego powinien wyświetlać stronę z wyjaśnieniem, jak przenieść aplikację na pierwszy plan i jak zainicjować żądanie OAuthGetAccessToken w aplikacji.

Tryb urządzenia

Jeśli aplikacja nie może uruchomić pełnej przeglądarki, urządzenia z bogatym klientem mogą też autoryzować bez przeglądarki.

Ten tryb umożliwia deweloperowi skonfigurowanie witryny, w której użytkownik może autoryzować prośbę o dostęp. Po autoryzacji użytkownik otrzymuje kod wygenerowany przez Google i jest przekierowywany do witryny dewelopera. Ta strona powinna zawierać instrukcje wpisywania kodu na urządzeniu użytkownika w celu ukończenia procesu autoryzacji.

Tryb programisty

Ten tryb jest zalecany tylko na wczesnym etapie tworzenia aplikacji.

Podobnie jak w trybie automatycznego wykrywania aplikacja musi uruchomić przeglądarkę, a użytkownik musi autoryzować żądanie. Zamiast tworzyć stronę internetową dla adresu URL wywołania zwrotnego, możesz ustawić wartość parametru oauth_callback na "oob" (poza pasmem).

W takim przypadku po autoryzacji prośby przez użytkownika Google przekierowuje go na stronę kont Google, na której wyświetla się numer weryfikacyjny (patrz przykład).

Użytkownik musi wrócić do aplikacji i wpisać numer weryfikacyjny, zanim będzie można wysłać żądanie OAuthGetAccessToken.

Więcej informacji o OAuth

Szczegółowe informacje o wdrożeniu protokołu OAuth przez Google, w tym o rejestrowaniu aplikacji i tworzeniu niezbędnych parametrów OAuth, znajdziesz w tych dodatkowych materiałach:

Powrót do góry

Używanie AuthSub do autoryzacji

AuthSub to zastrzeżony interfejs API autoryzacji Google, który jest dostępny jako alternatywa dla OAuth w przypadku większości interfejsów API Google. Jeśli to możliwe, unikaj używania AuthSub. Jeśli masz już aplikacje, które korzystają z AuthSub, przenieś je na OAuth lub protokół hybrydowy.

Proces autoryzacji AuthSub

Autoryzacja za pomocą AuthSub obejmuje sekwencję interakcji między 3 podmiotami: aplikacją internetową, usługami Google i użytkownikiem. Ten diagram ilustruje kolejność:

Proces autoryzacji

  1. Gdy aplikacja internetowa potrzebuje dostępu do usługi Google użytkownika, wysyła wywołanie AuthSub do usługi serwera proxy autoryzacji Google.
  2. Usługa autoryzacji odpowiada, wyświetlając stronę z prośbą o dostęp. Ta strona zarządzana przez Google prosi użytkownika o przyznanie lub odmowę dostępu do usługi Google. Użytkownik może najpierw zostać poproszony o zalogowanie się na konto.
  3. Użytkownik decyduje, czy przyznać dostęp do aplikacji internetowej. Jeśli użytkownik odmówi dostępu, zostanie przekierowany na stronę Google, a nie z powrotem do aplikacji internetowej.
  4. Jeśli użytkownik przyzna dostęp, usługa autoryzacji przekieruje go z powrotem do aplikacji internetowej. Przekierowanie zawiera token autoryzacji do jednorazowego użycia, który można wymienić na token długotrwały.
  5. Aplikacja internetowa kontaktuje się z usługą Google z żądaniem, używając tokena autoryzacji, aby działać w imieniu użytkownika.
  6. Jeśli usługa Google rozpozna token, przesyła dane, o które prosisz.

Praca z AuthSub

Włączenie AuthSub w aplikacji internetowej wymaga wykonania tych czynności:

  1. Zdecyduj, czy chcesz zarejestrować aplikację internetową.

    Zarejestrowane aplikacje internetowe są rozpoznawane przez Google, a standardowe ostrzeżenie wyświetlane użytkownikom na stronie logowania w Google jest modyfikowane lub pomijane. Dodatkowo zarejestrowane aplikacje internetowe są identyfikowane za pomocą nazwy opisowej, a nie tylko adresu URL wywołania. Pamiętaj, że niektóre usługi Google umożliwiają tylko ograniczony dostęp do niezarejestrowanych aplikacji internetowych. Jeśli zdecydujesz się zarejestrować, skorzystaj z tego automatycznego procesu rejestracji.

    Jeśli się zarejestrujesz, możesz też podać certyfikat bezpieczeństwa i klucze. Zarejestrowane aplikacje internetowe z certyfikatem w pliku mogą uzyskiwać bezpieczne tokeny do użycia podczas wysyłania próśb o dane z usługi Google. (W razie potrzeby mogą też używać niezabezpieczonych tokenów).

  2. Zdecyduj, jakich tokenów chcesz używać i jak nimi zarządzać.

    Token autoryzacji otrzymany od Google jest przeznaczony do wszystkich przyszłych interakcji z określoną usługą Google w przypadku danego użytkownika. Rodzaj tokena, którego chcesz użyć – jednorazowego lub sesyjnego – zależy od rodzaju interakcji, jakie Twoja aplikacja internetowa będzie mieć z usługą Google. Jeśli interakcja jest jednorazowa lub rzadka, wystarczy token jednorazowy.

    Jeśli zdecydujesz się pobierać tokeny sesji i regularnie używać ich do uzyskiwania dostępu do usługi Google, Twoja aplikacja internetowa będzie musiała zarządzać przechowywaniem tokenów, w tym śledzić użytkownika i usługę Google, dla której token jest ważny. Konta Google nie są przystosowane do zarządzania dużą liczbą tokenów i nie pozwalają na przechowywanie więcej niż 10 ważnych tokenów (na użytkownika i aplikację internetową) w danym momencie. To ograniczenie umożliwia aplikacji internetowej uzyskanie w razie potrzeby wielu tokenów obejmujących różne usługi. Nie obsługuje ono jednak uzyskiwania nowego tokena za każdym razem, gdy aplikacja internetowa potrzebuje dostępu do usługi Google. Jeśli zdecydujesz się przechowywać tokeny sesji, traktuj je tak samo bezpiecznie jak inne informacje wrażliwe przechowywane na serwerze.

    Możesz też regularnie uzyskiwać nowe tokeny, o ile skonfigurujesz mechanizm odwoływania tokenów. Zanim poprosisz o kolejny token, musisz unieważnić istniejący. W tym scenariuszu użytkownik będzie musiał się zalogować i przyznać dostęp za każdym razem, gdy zostanie wysłana prośba o nowy token.

  3. Określ zakres wymagany przez usługę Google, do której chcesz uzyskać dostęp.

    Każda usługa Google określa, jak duży i jakiego rodzaju dostęp będzie umożliwiać. Ten dostęp jest wyrażony jako wartość zakresu. Zakres usługi może być prostym adresem URL identyfikującym całą usługę lub może określać bardziej ograniczony dostęp. Niektóre usługi znacznie ograniczają dostęp, np. umożliwiają tylko odczyt ograniczonych informacji. Aby uzyskać listę dozwolonych zakresów dla usługi Google, do której chcesz uzyskać dostęp, zapoznaj się z dokumentacją tej usługi. Powinieneś(-aś) poprosić o token o jak najwęższym zakresie. Jeśli na przykład chcesz uzyskać dostęp do funkcji kanału Atom w Gmailu, użyj zakresu „http://www.google.com/calendar/feeds/”, a nie „http://www.google.com/calendar/”. Usługi Google są znacznie bardziej restrykcyjne w przypadku żądań o szerokim zakresie.

  4. Skonfiguruj mechanizm wysyłania próśb o token autoryzacji i jego odbierania.

    Mechanizm musi wygenerować prawidłowe wywołanie AuthSubRequest, w tym określić odpowiednie wartości URL next i scope (ustalone w kroku 3). Jeśli używasz bezpiecznych tokenów lub zarządzasz tokenami sesji, żądanie musi też zawierać wartości tych zmiennych.

    Następny adres URL może zawierać parametry zapytania. Na przykład w przypadku obsługi wielu języków dodaj parametr zapytania, który identyfikuje wersję aplikacji internetowej wyświetlaną przez użytkownika. Wartość next równa http://www.yoursite.com/Retrievetoken?Lang=de spowoduje przekierowanie http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE. Analizowanie tokena i parametru Lang zapewnia przekierowanie użytkownika z powrotem do właściwej wersji witryny.

    W pewnych okolicznościach użycie parametru hd może ułatwić użytkownikom przyznawanie dostępu w witrynie kont Google. W większości przypadków wystarczy zalogować się na konto i zdecydować, czy chcesz przyznać dostęp. Użytkownicy, którzy mają więcej niż 1 konto Google (zwykłe konto Gmail lub co najmniej 1 konto Google Apps hostowane), mogą jednak musieć przejść dodatkowy proces „uniwersalnego logowania”, aby określić, do którego konta chcą uzyskać dostęp. Jeśli aplikacja jest przeznaczona dla konkretnej domeny zarządzanej, możesz wyeliminować te dodatkowe kroki, używając tego parametru do zidentyfikowania domeny. Możesz też użyć parametru hd, jeśli Twoja aplikacja uzyskuje dostęp do usług, które nie są dostępne na kontach hostowanych. Ustawienie wartości „default” ograniczy autoryzację tylko do zwykłych kont. Gdy wartość parametru hd jest ustawiona, Google automatycznie wybierze odpowiednie konto do autoryzacji.

    Mechanizm tokena musi być w stanie przeanalizować przekierowanie otrzymane od Google, które zawiera token jednorazowy, i podjąć odpowiednie działanie. Tokeny autoryzacji są przypisane do konkretnego użytkownika, więc aplikacja musi być w stanie powiązać token z użytkownikiem. Zalecane jest wydanie użytkownikowi pliku cookie przed wysłaniem żądania tokena. Gdy Google przekieruje użytkownika z powrotem do Twojej witryny z dołączonym tokenem, aplikacja będzie mogła odczytać plik cookie i powiązać token z prawidłowym identyfikatorem użytkownika.

  5. Skonfiguruj mechanizmy żądania tokenów sesji oraz ich przechowywania lub odwoływania (w odpowiednich przypadkach).

    W zależności od decyzji dotyczących zarządzania tokenami podjętych w kroku 2 może być konieczne utworzenie mechanizmów pobierania i unieważniania tokenów sesji (AuthSubSessionToken i AuthSubRevokeToken). Aby przetestować mechanizmy sesji i unieważniania, użyj funkcji AuthSubTokenInfo, która wskazuje, czy dany token jest prawidłowy. Jeśli aplikacja przechowuje tokeny, musi śledzić zarówno identyfikator użytkownika, jak i usługę (zakres) objętą tokenem.

  6. Skonfiguruj mechanizm, który umożliwia wysyłanie próśb o dostęp do usługi Google.

    Informacje o właściwym formacie żądania znajdziesz w dokumentacji usługi Google. Wszystkie żądania wysyłane do usługi Google muszą zawierać prawidłowy token autoryzacji. Ogólnie rzecz biorąc, żądanie do usługi Google ma postać żądania HTTP GET (lub POST, jeśli zapisywane są nowe dane), a token jest przywoływany w nagłówku żądania.

    Nagłówek żądania powinien mieć następującą formę:

    Authorization: AuthSub token="token"

    gdzie token to token autoryzacji (jednorazowy lub sesyjny) otrzymany od Google w odpowiedzi na żądanie AuthSub. Jeśli token jest bezpieczny, musi mu towarzyszyć podpis cyfrowy. Instrukcje i przykłady znajdziesz w sekcji „Podpisywanie żądań”.

    Poniższy przykład ilustruje nagłówek żądania wywołania usługi kanału Kalendarza Google. To żądanie zawiera niezabezpieczony token: 

    GET /calendar/feeds/default/private/full HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="GD32CMCL25aZ-v____8B"
User-Agent: Java/1.5.0_06
Host: www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

Więcej informacji o AuthSub

Więcej informacji o AuthSub, w tym o rejestrowaniu aplikacji w Google i szczegółowym wyjaśnieniu procesu wymiany jednorazowego tokena na token sesji, znajdziesz w tych materiałach:

Powrót do góry

Używanie ClientLogin do autoryzacji

ClientLogin to zastrzeżony interfejs API autoryzacji Google, który jest dostępny jako alternatywa dla OAuth w przypadku większości interfejsów API Google. W miarę możliwości unikaj korzystania z ClientLogin. Jeśli masz już aplikacje, które korzystają z ClientLogin, przenieś je na OAuth lub protokół hybrydowy.

Uwierzytelnianie zainstalowanych aplikacji: ClientLogin

ClientLogin umożliwia użytkownikom logowanie się na konto Google z poziomu aplikacji. Aplikacja kontaktuje się następnie z Google, podając dane logowania i prosząc o dostęp do określonego interfejsu Google Data API. Po pomyślnym uwierzytelnieniu informacji logowania Google zwraca token, do którego aplikacja będzie się odwoływać za każdym razem, gdy poprosi o dostęp do konta użytkownika, np. w celu pobrania lub opublikowania danych. Token pozostaje ważny przez określony czas, który zależy od usługi Google, z której korzystasz.

Uwaga: biblioteki klienta interfejsów API danych Google udostępniają metody, które pomagają używać ClientLogin w zainstalowanych aplikacjach. W szczególności istnieją metody uzyskiwania tokena uwierzytelniania, obsługiwania wyzwań CAPTCHA, przywoływania tokena uwierzytelniania do późniejszego użycia i wysyłania prawidłowego nagłówka Authorization z każdym żądaniem. Jeśli korzystasz z jednej z tych bibliotek, zapoznaj się z artykułem Korzystanie z ClientLogin w bibliotekach klienta interfejsów Google Data API.

Proces autoryzacji ClientLogin

Autoryzacja za pomocą ClientLogin obejmuje sekwencję interakcji między 3 podmiotami: zainstalowaną aplikacją, usługami Google i użytkownikiem. Ten diagram ilustruje kolejność:

Proces autoryzacji

  1. Gdy aplikacja innej firmy potrzebuje dostępu do usługi Google użytkownika, pobiera jego nazwę logowania i hasło.
  2. Aplikacja innej firmy wywołuje następnie usługę autoryzacji Google za pomocą wywołania ClientLogin.
  3. Jeśli usługa autoryzacji Google uzna, że konieczne jest dodatkowe sprawdzenie, zwraca odpowiedź o błędzie z tokenem CAPTCHA i wyzwaniem w postaci adresu URL obrazu CAPTCHA.
  4. Jeśli aplikacja innej firmy otrzyma test CAPTCHA, wyświetli obraz CAPTCHA użytkownikowi i poprosi go o odpowiedź.
  5. Jeśli pojawi się prośba, użytkownik przesyła odpowiedź na test CAPTCHA.
  6. Aplikacja innej firmy wykonuje nowe wywołanie ClientLogin, tym razem z odpowiedzią na CAPTCHA i tokenem (otrzymanym w odpowiedzi o błędzie).
  7. W przypadku udanej próby logowania (z wyzwaniem CAPTCHA lub bez niego) usługa autoryzacji Google zwraca token do aplikacji.
  8. Aplikacja kontaktuje się z usługą Google, wysyłając prośbę o dostęp do danych i odwołując się do tokena otrzymanego z usługi autoryzacji Google.
  9. Jeśli usługa Google rozpozna token, przyzna dostęp do żądanych danych.

Korzystanie z uwierzytelniania ClientLogin

Użyj tego interfejsu w zainstalowanej aplikacji, aby programowo uzyskać dostęp do konta Google użytkownika. Po zebraniu od użytkownika informacji logowania wywołaj ClientLogin, aby poprosić o dostęp do jego konta. Po pomyślnym uwierzytelnieniu informacji logowania Google zwraca token, do którego Twoja aplikacja będzie się odwoływać za każdym razem, gdy poprosi o dostęp do konta użytkownika. Token pozostaje ważny przez określony czas, który zależy od usługi Google, z której korzystasz.

Wprowadzenie ClientLogin do aplikacji wymaga wykonania tych zadań:

  1. Utwórz element interfejsu, który będzie rejestrować dane logowania użytkownika.

    Interfejs użytkownika musi prosić o nazwę użytkownika (adres e-mail z domeną) i hasło. Interfejs powinien też umożliwiać wyświetlanie obrazu CAPTCHA przy użyciu adresu URL otrzymanego od Google (jeśli jest wymagany) i prosić użytkownika o podanie prawidłowej odpowiedzi. Najlepiej, aby interfejs użytkownika zawierał link do strony logowania na konta Google („https://www.google.com/accounts/Login”) na wypadek, gdyby użytkownik musiał zarejestrować nowe konto lub wykonać inne czynności związane z jego obsługą.

  2. Napisz kod, który wygeneruje prawidłowo sformatowane żądanie HTTPS POST ClientLogin i je prześle.

    Ten kod musi zawierać logikę obsługi testu CAPTCHA oraz parametry logintoken i logincaptcha. Aplikacja powinna też wykrywać, kiedy użytkownik pomija wymagane informacje lub powtarza nieprawidłowe dane po nieudanej próbie logowania, i wyświetlać błąd bez wysyłania zbędnego żądania.

  3. Obsługiwanie odpowiedzi od Google.

    Na żądanie logowania mogą być 4 rodzaje odpowiedzi:

    • sukces (HTTP 200),
    • niepowodzenie (HTTP 403) z wyjaśniającym kodem błędu.
    • nieprawidłowe żądanie, zwykle wynikające z nieprawidłowo sformułowanego żądania;
    • niepowodzenie w przypadku testu CAPTCHA,

    Odpowiedź informująca o powodzeniu zawiera token autoryzacji oznaczony jako „Auth”. Ten token musi być uwzględniany we wszystkich kolejnych żądaniach wysyłanych do usługi Google w przypadku tego konta. Tokeny autoryzacji powinny być starannie chronione i nie należy ich udostępniać żadnej innej aplikacji, ponieważ zapewniają one dostęp do konta użytkownika. Czas limit tokena zależy od usługi, która go wydała.

    Odpowiedź z informacją o niepowodzeniu zawiera co najmniej jeden kod błędu i adres URL z komunikatem o błędzie, który można wyświetlić użytkownikowi. Pamiętaj, że ClientLogin nie rozróżnia niepowodzenia spowodowanego nieprawidłowym hasłem od niepowodzenia spowodowanego nierozpoznaną nazwą użytkownika (np. jeśli użytkownik nie zarejestrował jeszcze konta w ClientLogin). Aplikacja musi odpowiednio obsługiwać wszystkie możliwe komunikaty o błędach.

    Odpowiedź o błędzie z wyzwaniem CAPTCHA oznacza, że z jakiegoś powodu Google uznało, że należy podjąć dodatkowe środki bezpieczeństwa. Odpowiedzi towarzyszy adres URL obrazu CAPTCHA i token reprezentujący konkretne zadanie CAPTCHA.

  4. Rozwiązywanie zadań CAPTCHA od Google.

    Aby rozwiązać test, aplikacja musi wyświetlić obraz CAPTCHA i poprosić użytkownika o odpowiedź. Aby wyświetlić obraz CAPTCHA, użyj wartości CaptchaUrl zwróconej w odpowiedzi o błędzie, dodając przed nią adres URL kont Google: „http://www.google.com/accounts/". Gdy użytkownik poda odpowiedź, aplikacja powinna ponownie wysłać żądanie logowania, tym razem z tokenem CAPTCHA (logintoken) i odpowiedzią użytkownika (logincaptcha). Google weryfikuje odpowiedź użytkownika przed autoryzacją dostępu do konta.

    Deweloperzy, którzy nie chcą zarządzać procesami uzyskiwania i przesyłania odpowiedzi użytkownika na CAPTCHA, mogą skorzystać z alternatywnego rozwiązania. W odpowiedzi na test CAPTCHA aplikacja może przekierować użytkownika na stronę hostowaną przez Google: „https://www.google.com/accounts/DisplayUnlockCaptcha”. Gdy użytkownik pomyślnie odpowie na pytanie weryfikacyjne, serwer Google uzna używany komputer za zaufany. Aplikacja może wtedy ponownie wysłać pierwotną prośbę o zalogowanie, aby uzyskać token autoryzacji.

    5. Uwaga: przed wyświetleniem testu CAPTCHA Google nie weryfikuje próby logowania. Oznacza to, że próba logowania może się nie powieść nawet po rozwiązaniu testu CAPTCHA.

* CAPTCHA jest znakiem towarowym Carnegie Mellon University

Powrót do góry

Uwierzytelnianie gadżetów

Serwer proxy OAuth

Jeśli tworzysz gadżet przy użyciu standardowego interfejsu Gadgets API, możesz skorzystać z funkcji platformy gadżetów o nazwie OAuth Proxy, aby uzyskać dostęp do interfejsów Google Data API. OAuth (opisany powyżej) to standard uwierzytelniania, który umożliwia użytkownikom dostęp do ich prywatnych danych w usłudze hostingu gadżetów, takiej jak iGoogle, MySpace czy Orkut, lub udostępnianie danych innej witrynie lub gadżetowi. Serwer proxy OAuth został zaprojektowany, aby ułatwić deweloperom gadżetów tworzenie aplikacji przez ukrywanie wielu szczegółów uwierzytelniania OAuth. Serwer proxy jest oparty na projekcie open source o nazwie Shindig, który jest implementacją specyfikacji gadżetów.

Uwaga: serwer proxy OAuth jest obsługiwany tylko w przypadku gadżetów, które korzystają z interfejsu gadgets.* API i działają w kontenerach OpenSocial. Nie jest on obsługiwany w przypadku starszego interfejsu API gadżetów.

Proces uwierzytelniania

Zanim gadżet uzyska dostęp do danych użytkownika, musi otrzymać token OAuth. Serwer proxy OAuth zarządza procesem uwierzytelniania. Gdy użytkownik zainstaluje gadżet po raz pierwszy, nastąpi ten proces:

  1. Gadżet wczytuje się po raz pierwszy i próbuje uzyskać dostęp do danych użytkownika za pomocą jednego z interfejsów Google Data API.
  2. Żądanie nie zostało zrealizowane, ponieważ użytkownik nie przyznał dostępu. Obiekt odpowiedzi zawiera adres URL (w response.oauthApprovalUrl) strony zatwierdzania OAuth. Gadżet powinien umożliwiać otwieranie nowego okna z tym adresem URL.
  3. Na stronie zatwierdzania użytkownik może przyznać lub odmówić dostępu do gadżetu. Jeśli się powiedzie, użytkownik zostanie przekierowany na stronę oauth_callback, którą określisz. Aby zapewnić użytkownikom jak największą wygodę, używaj http://oauth.gmodules.com/gadgets/oauthcallback.
  4. Następnie użytkownik zamyka wyskakujące okienko. Aby powiadomić gadżet o tym, że użytkownik zatwierdził dostęp, możesz użyć procedury obsługi wyskakującego okienka do wykrywania zamknięcia okna zatwierdzania. Gadżet może też wyświetlać link (np. „Zatwierdzam dostęp”), który użytkownik może kliknąć po zamknięciu tego okna.
  5. Gadżet próbuje uzyskać dostęp do interfejsu Google Data API po raz drugi, ponownie wysyłając prośbę o dane użytkownika. Próba zakończyła się powodzeniem.
  6. Gadżet zostanie uwierzytelniony i będzie mógł działać normalnie.

Konfiguracja gadżetu

Aby uzyskać dostęp do co najmniej jednego interfejsu Google Data API, musisz najpierw poinformować gadżet, że ma używać OAuth jako metody uwierzytelniania. Dodaj element <OAuth> w sekcji <ModulePrefs> pliku XML gadżetu:

<ModulePrefs>
...
<OAuth>
  <Service name="google">
    <Access url="https://www.google.com/accounts/OAuthGetAccessToken" method="GET" />
    <Request url="https://www.google.com/accounts/OAuthGetRequestToken?
                  scope=http://www.blogger.com/feeds/%20http://www.google.com/calendar/feeds/" method="GET" />
    <Authorization url="https://www.google.com/accounts/OAuthAuthorizeToken?
                        oauth_callback=http://oauth.gmodules.com/gadgets/oauthcallback" />
  </Service>
</OAuth>
...
</ModulePrefs>

W tej sekcji zmieniaj tylko te parametry zapytania:

scope
Wymagany parametr w adresie URL żądania. Gadżet może uzyskiwać dostęp do danych z scope użytych w tym parametrze. W tym przykładzie gadżet ma dostęp do danych z Blogera i Kalendarza. Gadżet może wysyłać żądania danych w ramach jednego lub kilku zakresów, jak w tym przykładzie.
oauth_callback
Opcjonalny parametr w adresie URL autoryzacji. Strona akceptacji OAuth przekierowuje na ten adres URL po tym, jak użytkownik zatwierdzi dostęp do danych. Aby zapewnić użytkownikom jak najlepsze wrażenia podczas instalowania gadżetu, ustaw ten parametr na http://oauth.gmodules.com/gadgets/oauthcallback. Na tej stronie znajduje się fragment kodu JavaScript, który automatycznie zamyka wyskakujące okienko. Możesz też ustawić ten parametr tak, aby wskazywał Twoją „zatwierdzoną” stronę, lub po prostu pozostawić go pustego.

Uzyskiwanie dostępu do uwierzytelnionego pliku danych Google API

Gdy gadżet uwierzytelni użytkownika, dostęp do interfejsu Google Data API będzie prosty dzięki bibliotece klienta JavaScript interfejsów Google Data API. Informacje o używaniu biblioteki w usłudze OAuth Proxy znajdziesz w artykule Korzystanie z biblioteki klienta JavaScript.

Więcej informacji o gadżetach

Pełne informacje o tworzeniu gadżetów interfejsu Google Data API, w tym szczegóły dotyczące serwera proxy OAuth, artykuł o tym, jak zacząć, oraz specyfikacja gadgets.* znajdziesz w tych dodatkowych materiałach:

Powrót do góry