Uwierzytelnianie i autoryzacja w protokole Google Data Protocol

Ostrzeżenie: ta strona dotyczy starszych interfejsów API Google – interfejsów API danych Google – dotyczy tylko interfejsów API wymienionych w katalogu interfejsów API danych Google, z których wiele zostało zastąpionych nowszych. Informacje na temat konkretnego nowego interfejsu API można znaleźć w dokumentacji nowego interfejsu API. 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 określonych rodzajów aktywności. Aby mieć pewność, że dane użytkowników nie są nadużywane, wszystkie prośby o dostęp muszą zostać zatwierdzone przez właściciela konta. Kontrola dostępu obejmuje 2 komponenty: uwierzytelnianie i autoryzację.

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

Usługi autoryzacji pozwalają użytkownikom udostępniać aplikacji dane, które przechowujeją w aplikacjach Google. Google poważnie traktuje prywatność, a każda aplikacja, która wymaga dostępu do danych użytkownika, musi mieć autoryzację.

Usługi uwierzytelniania i autoryzacji są często określane zbiorczo jako auth (uwierzytelnianie).

Uwierzytelnianie i autoryzacja interfejsów API Google pozwala aplikacjom innych firm na ograniczony dostęp do konta Google użytkownika w przypadku określonych rodzajów aktywności. Ten dokument przedstawia dostępne mechanizmy uwierzytelniania i opisuje, co oferuje każdy z nich.

  • Logowanie przez Google to prosty sposób na logowanie się w Twojej witrynie za pomocą danych logowania Google. Zawiera zestaw narzędzi, które można łatwo zintegrować na różnych urządzeniach.
  • OAuth 2.0 to protokół autoryzacji obejmujący wszystkie interfejsy API Google. Protokół OAuth 2.0 opiera się na zabezpieczeniach SSL, zamiast wymagać od aplikacji bezpośredniego podpisywania kryptograficznego. Protokół ten umożliwia aplikacji żądanie dostępu do danych powiązanych z kontem Google użytkownika.
  • Logowanie przy użyciu protokołu OAuth 2.0 (OpenID Connect) uwierzytelnia użytkowników przez logowanie się na ich konta Google. Zastąpi go OpenID, a użytkownicy OpenID planują migrację do logowania z użyciem protokołu OAuth 2.0.

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

Uwaga: ten dokument zawiera ogólny opis każdej metody uwierzytelniania. Szczegółowe informacje na temat poszczególnych metod znajdziesz w pełnej dokumentacji interfejsów API uwierzytelniania konta Google.

Przeczytaj też artykuł o grupie interfejsów API kont Google, by dowiedzieć się więcej o korzystaniu z interfejsów API kont Google.

OAuth – autoryzacja w przypadku witryn i zainstalowanych aplikacji

Wiele usług Google umożliwia osobom trzecim dostęp do danych wygenerowanych przez użytkownika, takich jak dane z Kalendarza czy Dokumentów, o ile użytkownik wyraził na to zgodę. Funkcja ta umożliwia użytkownikom udostępnianie danych i wymianę danych między aplikacjami Google a aplikacjami innych firm w różnych celach.

Google obsługuje 2 wersje protokołu OAuth, aby uzyskać autoryzowany dostęp do danych Google użytkownika: OAuth 1.0 i OAuth 2.0. Oba te rozwiązania zapewniają dostęp do aplikacji internetowych i zainstalowanych.

OAuth 2.0 w przypadku internetu i zainstalowanych aplikacji

Aplikacje internetowe i zainstalowane aplikacje mogą korzystać z 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 OAuth 2.0 z Google znajdziesz w dokumentacji OAuth 2.0.

OAuth 1.0 dla aplikacji internetowych

Aplikacje internetowe wymagające autoryzowanego dostępu do danych powiązanych z kontem Google lub z kontem Google Apps mogą korzystać z implementacji interfejsu OAuth API przez Google. Pełne informacje na temat wdrażania protokołu OAuth w aplikacjach internetowych, w tym przykłady, znajdziesz w przewodniku OAuth for Web Apps lub w tym omówieniu tego dokumentu.

OAuth 1.0 w przypadku zainstalowanych aplikacji

Aplikacje zainstalowane na komputerach i urządzeniach mobilnych użytkowników mogą autoryzować dostęp do danych powiązanych z kontem Google przy użyciu protokołu OAuth. Pełne informacje na temat wdrażania protokołu OAuth dla zainstalowanych aplikacji znajdziesz w przewodniku po protokole OAuth dla zainstalowanych aplikacji lub w omówieniu tego dokumentu.

Korzystanie z protokołu OAuth w aplikacjach internetowych

Wszystkie interfejsy API danych Google obsługują OAuth – otwarty standard autoryzacji użycia danych w aplikacjach internetowych. Wszystkie aplikacje internetowe wysyłające żądania OAuth muszą przesłać certyfikat bezpieczeństwa i zarejestrować się w Google. Więcej informacji znajdziesz w artykule Rejestracja w aplikacjach internetowych.

Biblioteki klienta interfejsów API danych Google udostępniają metody ułatwiające korzystanie z protokołu OAuth w aplikacji internetowej. Konkretnie chodzi o metody tworzenia tokena żądania, autoryzowania tokena żądania i wymiany autoryzowanego tokena żądania na token dostępu. Biblioteki obsługują też niezbędne algorytmy podpisywania, gdy wysyłają żądania do usługi danych Google. Dokładne przykłady użycia protokołu OAuth z bibliotekami klienta interfejsu API danych Google znajdziesz w artykule Korzystanie z protokołu OAuth w bibliotekach klienta interfejsów API danych Google.

Proces autoryzacji OAuth

Proces autoryzacji OAuth obejmuje szereg interakcji między aplikacją internetową, serwerami autoryzacji Google a użytkownikami.

Proces podstawowy wygląda w ten sposób:

  1. Twoja aplikacja prosi o dostęp i otrzymuje nieautoryzowany token żądania z serwera autoryzacji Google.
  2. Google prosi użytkownika o przyznanie dostępu do wymaganych danych.
  3. Twoja aplikacja otrzyma autoryzowany token żądania z serwera autoryzacji.
  4. Wymieniasz autoryzowany token żądania dla tokena dostępu.
  5. Token dostępu służy do wysyłania żądań danych do serwerów dostępu Google.

Gdy aplikacja początkowo prosi o dostęp do danych użytkownika, Google wysyła do niej nieautoryzowany token żądania.

W razie potrzeby użytkownik zobaczy prośbę o zalogowanie się. Następnie Google wyświetla stronę autoryzacji, na której użytkownik może sprawdzić, do jakich danych usługi Google chce uzyskać dostęp Twoja aplikacja.

Jeśli użytkownik zaakceptuje prośbę o dostęp do aplikacji, Google wyda autoryzowany token żądania. Każdy token żądania jest ważny tylko przez godzinę. Można wymienić tylko autoryzowany token żądania dla tokena dostępu. Można to zrobić tylko raz na każdy autoryzowany token żądania.

Domyślnie tokeny dostępu są ważne przez dłuższy czas. Każdy token dostępu jest przypisany do konta użytkownika wskazanego w pierwotnym wniosku o autoryzację i daje dostęp tylko do usług określonych w tym żądaniu. Aplikacja powinna bezpiecznie przechowywać token dostępu, ponieważ jest on wymagany do wszystkich danych użytkownika.

Przygotowanie do protokołu OAuth

Zanim skonfigurujesz aplikację do korzystania z usługi Google Authorization z użyciem protokołu OAuth, musisz wykonać te czynności.

Podejmowanie decyzji, czy zarejestrować aplikację internetową

Aby zapewnić użytkownikom dodatkowe bezpieczeństwo danych, możesz zarejestrować swoją aplikację internetową w Google i podpisać żądania za pomocą zarejestrowanego certyfikatu zabezpieczeń. Niektóre pliki danych interfejsu Google Data API są dostępne tylko dla zarejestrowanych aplikacji. Sprawdź w dokumentacji interfejsu Google Data API, czy ten interfejs działa tylko z zarejestrowanymi aplikacjami.

Aplikacja musi podpisać wszystkie wysyłane żądania OAuth. Jeśli do podpisywania żądań zdecydujesz się używać podpisu RSA-SHA1, w ramach procesu rejestracji musisz przesłać certyfikat bezpieczeństwa.

Do podpisania żądań możesz też użyć podpisu HMAC-SHA1. Podpisy HMAC-SHA1 nie wymagają certyfikatu. Zamiast tego Google generuje wartość OAuth consumer secret, która jest wyświetlana na stronie rejestracji domeny po rejestracji.

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

Określam zakres danych, do których aplikacja będzie miała dostęp

Każda usługa Google określa limity dostępu, które zezwala za pomocą interfejsów API danych Google. Ten dostęp jest wyrażony jako wartość zakresu. Niektóre usługi udostępniają różne wartości zakresu, dzięki którym użytkownicy mogą decydować, które aplikacje powinny mieć dostęp do których danych. Informacje o dostępnych wartościach zakresu usługi Google, do której chcesz uzyskać dostęp, znajdziesz w dokumentacji tej usługi.

Ogólnie należy zażądać tokena o najwęższym zakresie zawierającym potrzebne dane. Jeśli na przykład aplikacja wymaga dostępu do kanału „Wszystkie kalendarze” użytkownika, poproś o token dla zakresu http://www.google.com/calendar/feeds/default/allcalendars/full.

Konfigurowanie mechanizmu zarządzania tokenami OAuth

Po uzyskaniu tokena dostępu OAuth do danych użytkownika musisz go używać w przypadku wszystkich przyszłych interakcji z określoną usługą Google w imieniu użytkownika.

Aplikacja powinna bezpiecznie zarządzać miejscem na tokeny, w tym za pomocą śledzenia usługi Google, dla której każdy token jest prawidłowy. Jeśli potrzebujesz dostępu do więcej niż 1 usługi Google, możesz uzyskać wiele tokenów dostępu, ale nie więcej niż 10 tokenów dostępu dla każdego użytkownika i aplikacji może zostać wyodrębnionych w dowolnym czasie.

Jeśli 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 być w stanie powiązać token z właściwym użytkownikiem. Jednym ze sposobów na zarządzanie tym jest wysłanie pliku cookie do użytkownika 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.

Konfigurowanie mechanizmu wysyłania próśb o dostęp do usługi Google

Każde żądanie wysyłane do usługi Google musi być podpisane i musi zawierać prawidłowy token dostępu OAuth. Ogólnie każde żądanie jest wysyłane w postaci żądania HTTP GET, z nagłówkiem i podpisem dostępu. Żądania, które zapisują nowe dane, powinny używać żądania POST HTTP.

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

Implementacja OpenID (opcjonalnie)

Jeśli implementujesz protokół OpenID do uwierzytelniania użytkowników, rozważ połączenie protokołu hybrydowego. W przypadku OpenID+OAuth zadania związane z pobieraniem tokena żądania i jego autoryzacją są obsługiwane w ramach żądania OpenID z rozszerzeniami OAuth. Tak jak OAuthGetRequestToken, rozszerzenia te służą do identyfikowania usług Google, do których chcesz uzyskać dostęp. Pomyślna odpowiedź na żądanie OpenID zawiera autoryzowany token żądania. Po otrzymaniu tego tokena użyj OAuthGetAccessToken, by wymienić go na token dostępu.

Używanie tokenów OAuth

Aby używać protokołu OAuth, aplikacja musi generować prawidłowo sformułowane, podpisane wywołania żądań i obsługiwać odpowiedzi w następujący sposób:

  1. Uzyskanie nieautoryzowanego tokena żądania (OAuthGetRequestToken)
  2. Autoryzuj token żądania (OAuthAuthorizeToken)
  3. Wymień autoryzowany token żą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 żądaniami tokenów autoryzacji i ich odbiorem w OAuth Playground.

Szczegółową dokumentację znajdziesz w dokumentacji interfejsu OAuth API.

Ustawianie adresu URL wywołania zwrotnego

W żądaniu OAuthGetRequestToken możesz określić wartość oauth_callback, aby określić, gdzie Google przekieruje użytkownika po autoryzacji żądania dostępu. URL wywołania zwrotnego może zawierać parametry zapytania. Przekierowanie będzie zawierało te same parametry zapytania, a także autoryzowany token żądania, który aplikacja musi być w stanie przeanalizować.

Gdy np. obsługujesz wiele języków, możesz dodać parametr zapytania identyfikujący wersję aplikacji oglądanej przez użytkownika. Wartość oauth_callback „http://www.twojawitryna.pl/Fetchtoken?Lang=de” spowodowałaby przekierowanie „http://www.twojawitryna.pl/Fetchtoken?Lang=de&oauth_token=DQAADKEDE”. Przeanalizuj token i parametr języka, by się upewnić, że użytkownik zostanie przekierowany z powrotem do właściwej wersji witryny.

Jeśli parametr oauth_callback nie zostanie podany, Google autoryzuje Twoją prośbę o dostęp do strony internetowej, na której wyświetla się numer weryfikacyjny (zobacz przykład). Aby uzyskać autoryzowany token żądania, użytkownik musi samodzielnie wrócić do aplikacji i wpisać numer weryfikacyjny.

Identyfikowanie aplikacji wśród 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 określić nazwę aplikacji. Jeśli nie podasz tego parametru, 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 „anonimowy”.

Nie ustawiaj tego parametru, jeśli Twoja aplikacja jest zarejestrowana. Domyślnie Google wyświetla wyświetlaną nazwę podaną podczas rejestracji. Jeśli w żądaniu OAuthGetRequestToken ustawisz nazwę wyświetlaną, Google będzie używać jej zamiast zarejestrowanej nazwy, dołączając komunikat, że nie można zweryfikować tożsamości aplikacji.

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

Praca z domenami Google Apps

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

Więcej informacji o protokole OAuth

Szczegółowe informacje o implementowaniu protokołu OAuth w Google, w tym o tym, jak zarejestrować aplikację i skonstruować niezbędne parametry OAuth, znajdziesz w tych materiałach:

Powrót do góry

Używanie protokołu OAuth z zainstalowanymi aplikacjami

Wszystkie interfejsy API danych Google obsługują OAuth – otwarty standard autoryzacji użycia danych w aplikacjach. Aby używać protokołu OAuth, zainstalowane aplikacje nie muszą być zarejestrowane w Google.

Proces autoryzacji OAuth

Proces autoryzacji OAuth obejmuje szereg interakcji między aplikacją, serwerami autoryzacji Google a użytkownikami końcowymi.

Proces podstawowy wygląda w ten sposób:

  1. Twoja aplikacja prosi o dostęp i otrzymuje nieautoryzowany token żądania z serwera autoryzacji Google.
  2. Google prosi użytkownika o przyznanie dostępu do wymaganych danych.
  3. Twoja aplikacja otrzyma autoryzowany token żądania z serwera autoryzacji.
  4. Wymieniasz autoryzowany token żądania dla tokena dostępu.
  5. Token dostępu służy do wysyłania żądań danych do serwerów dostępu Google.

Gdy aplikacja początkowo prosi o dostęp do danych użytkownika, Google wysyła do niej nieautoryzowany token żądania.

W razie potrzeby użytkownik zobaczy prośbę o zalogowanie się. Następnie Google wyświetla stronę autoryzacji, na której użytkownik może sprawdzić, do jakich danych usługi Google chce uzyskać dostęp Twoja aplikacja.

Jeśli użytkownik zaakceptuje prośbę o dostęp do aplikacji, Google wyda autoryzowany token żądania. Każdy token żądania jest ważny tylko przez godzinę. Można wymienić tylko autoryzowany token żądania dla tokena dostępu. Można to zrobić tylko raz na każdy autoryzowany token żądania.

OAuth obsługuje zainstalowane aplikacje za pomocą trybu niezarejestrowanego. Istnieje wiele metod uzyskiwania autoryzowanego tokena żądania. Aplikacja może autoryzować dostęp aplikacji za pomocą protokołu OAuth, nawet jeśli na urządzeniu, na którym jest zainstalowana, nie ma przeglądarki.

Domyślnie tokeny dostępu są ważne przez dłuższy czas. Każdy token dostępu jest przypisany do konta użytkownika wskazanego w pierwotnym wniosku o autoryzację i daje dostęp tylko do usług określonych w tym żądaniu. Aplikacja powinna bezpiecznie przechowywać token dostępu, ponieważ jest on wymagany do wszystkich danych użytkownika.

Przygotowanie do protokołu OAuth

Zanim skonfigurujesz aplikację do korzystania z usługi Google Authorization z użyciem protokołu OAuth, musisz wykonać te czynności.

Określam zakres danych, do których aplikacja będzie miała dostęp

Każda usługa Google określa limity dostępu, które zezwala za pomocą interfejsów API danych Google. Ten dostęp jest wyrażony jako wartość zakresu. Niektóre usługi udostępniają różne wartości zakresu, dzięki którym użytkownicy mogą decydować, które aplikacje powinny mieć dostęp do których danych. Informacje o dostępnych wartościach zakresu usługi Google, do której chcesz uzyskać dostęp, znajdziesz w dokumentacji tej usługi.

Ogólnie należy zażądać tokena o najwęższym zakresie zawierającym potrzebne dane. Jeśli na przykład aplikacja wymaga dostępu do kanału „Wszystkie kalendarze” użytkownika, poproś o token dla zakresu http://www.google.com/calendar/feeds/default/allcalendars/full.

Konfigurowanie mechanizmu zarządzania tokenami OAuth

Po uzyskaniu tokena dostępu OAuth do danych użytkownika musisz go używać w przypadku wszystkich przyszłych interakcji z określoną usługą Google w imieniu użytkownika.

Aplikacja powinna bezpiecznie zarządzać miejscem na tokeny, w tym za pomocą śledzenia usługi Google, dla której każdy token jest prawidłowy.

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

Konfigurowanie mechanizmu wysyłania próśb o dostęp do usługi Google

Każde żądanie wysyłane do usługi Google musi być podpisane i musi zawierać prawidłowy token dostępu OAuth. Ogólnie każde żądanie jest wysyłane w postaci żądania HTTP GET, z nagłówkiem i podpisem dostępu. Żądania, które zapisują nowe dane, powinny używać żądania POST HTTP.

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

Używanie tokenów OAuth

Aby używać protokołu OAuth, aplikacja musi generować prawidłowo sformułowane, podpisane wywołania żądań i obsługiwać odpowiedzi w następujący sposób:

  1. Uzyskanie nieautoryzowanego tokena żądania (OAuthGetRequestToken)
  2. Autoryzuj token żądania (OAuthAuthorizeToken)
  3. Wymień autoryzowany token żą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 być zgodne z instrukcjami dotyczącymi niezarejestrowanych aplikacji.

Możesz eksperymentować z żądaniami tokenów autoryzacji i ich odbiorem w OAuth Playground.

Szczegółową dokumentację znajdziesz w dokumentacji interfejsu OAuth API.

Identyfikowanie aplikacji wśród użytkowników

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

Aby określić nazwę aplikacji, użyj parametru xoauth_displayname w żądaniu OAuthGetRequestToken. Jeśli nie podasz tego parametru, 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 „anonimowy”.

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

Uruchamianie przeglądarki

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

  • Trybu automatycznego wykrywania powinien być używany w większości aplikacji
  • Trybu urządzenia należy używać w aplikacjach, które nie mogą uruchamiać pełnej przeglądarki.
  • Trybu programowania używaj tylko na wczesnym etapie tworzenia.

Tryb automatycznego wykrywania

Jeśli to możliwe, aplikacja powinna uruchomić okno przeglądarki i przesłać żądanie OAuthAuthorizeToken do otwarcia strony Google. Gdy Google zwróci autoryzowany token, aplikacja powinna go wykryć i odzyskać fokus z przeglądarki.

Ten tryb wymaga podania adresu URL wywołania zwrotnego, do którego przekierowywany jest użytkownik po autoryzowaniu żądania dostępu. Ten adres URL musi być podany jako parametr oauth_callback w żądaniu OAuthGetRequestToken i jako parametr verifier żądania OAuthGetAccessToken.

Aby zwiększyć wygodę użytkowników, aplikacja powinna automatycznie wykrywać, kiedy użytkownik jest przekierowywany pod ten adres URL, oraz automatycznie przenosić się na pierwszy plan i wysyłać żądanie OAuthGetAccessToken do ukończenia procesu OAuth.

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

Jeśli aplikacja nie może automatycznie wykryć, że użytkownik jest przekierowywany na adres URL wywołania zwrotnego, ani nie może przenieść się na pierwszy plan, adres URL wywołania zwrotnego powinien zawierać stronę z informacjami o tym, jak przenieść aplikację na pierwszy plan i jak inicjować w niej żądanie OAuthGetAccessToken.

Tryb urządzenia

Jeśli aplikacja nie może uruchomić pełnej przeglądarki, urządzenia multimedialne mogą też autoryzować ją bez użycia 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 przekierowywany na stronę dewelopera. Ta witryna powinna wyjaśnić użytkownikowi, jak wpisać kod na urządzeniu, aby ukończyć proces autoryzacji.

Tryb programisty

Tryb ten jest zalecany tylko na wczesnym etapie tworzenia aplikacji.

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

W takim przypadku, gdy użytkownik autoryzuje Twoją prośbę, Google skieruje go na stronę kont Google z numerem weryfikacyjnym (zobacz przykład).

Przed wysłaniem żądania OAuthGetAccessToken użytkownik musi wrócić do aplikacji i wpisać numer weryfikacyjny.

Więcej informacji o protokole OAuth

Szczegółowe informacje o implementowaniu protokołu OAuth w Google, w tym o tym, jak zarejestrować aplikację i skonstruować niezbędne parametry OAuth, znajdziesz w tych materiałach:

Powrót do góry

Autoryzacja za pomocą AuthSub

AuthSub to zastrzeżony przez Google interfejs API autoryzacji, dostępny jako alternatywa dla protokołu OAuth w przypadku większości interfejsów API Google. Jeśli to możliwe, unikaj AuthSub. Jeśli masz już aplikacje korzystające z AuthSub, należy przejść na OAuth lub protokół hybrydowy.

Proces autoryzacji AuthSub

Autoryzacja z AuthSub obejmuje sekwencję interakcji między 3 elementami: aplikacją internetową, usługami Google i użytkownikiem. Ten diagram pokazuje sekwencję:

Proces autoryzacji

  1. Gdy aplikacja internetowa musi uzyskać dostęp do usługi Google użytkownika, wysyła żądanie AuthSub do usługi Authorization Proxy Google.
  2. Usługa Autoryzacja wysyła odpowiedź, udostępniając stronę żądania dostępu. Na tej stronie zarządzanej przez Google użytkownik otrzymuje prośbę o przyznanie dostępu do usługi Google. Użytkownik może najpierw zostać poproszony o zalogowanie się na swoje konto.
  3. Użytkownik decyduje, czy przyznać lub zablokować dostęp do aplikacji internetowej. Jeśli użytkownik odmówi dostępu, zostanie przekierowany na stronę Google, a nie do aplikacji internetowej.
  4. Jeśli użytkownik przyzna dostęp, usługa autoryzacyjna przekieruje go z powrotem do aplikacji internetowej. Przekierowanie zawiera token autoryzacji, który służy do jednorazowego użytku. Można go wymienić na długotrwały token.
  5. Aplikacja internetowa kontaktuje się z usługą Google za pomocą żądania i używa tokena tokena do działania jako klient użytkownika.
  6. Jeśli usługa Google rozpozna token, dostarczy żądane dane.

Praca z AuthSub

Wdrożenie AuthSub w aplikacji internetowej wymaga tych zadań:

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

    Zarejestrowane aplikacje internetowe mają tę zaletę, że są rozpoznawane przez Google – standardowe powiadomienie wyświetlane użytkownikom na stronie logowania Google jest zmieniane lub pomijane. Ponadto zarejestrowane aplikacje internetowe są określane za pomocą nazwy opisowej, a nie samego adresu URL wywołania. Pamiętaj, że niektóre usługi Google umożliwiają tylko ograniczony dostęp do niezarejestrowanych aplikacji internetowych. Skorzystaj z automatycznego procesu rejestracji.

    Podczas rejestracji możesz też podać certyfikat bezpieczeństwa i klucze. Zarejestrowane aplikacje internetowe z certyfikatem zarejestrowanym w sieci mogą pobierać bezpieczne tokeny do wykorzystania z żądaniami danych z usługi Google. (W razie potrzeby mogą też używać niezabezpieczonych tokenów).

  2. Wybierz typ tokenów, którego chcesz używać, i sposób zarządzania nimi.

    Token autoryzacyjny otrzymany od Google powinien być używany do wszystkich przyszłych interakcji tego użytkownika z określoną usługą Google. Typ tokena, który wybierzesz – jednorazowy lub sesja – zależy od typu interakcji Twojej aplikacji internetowej z usługą Google. Na przykład token jednorazowy może być wystarczający, jeśli interakcja jest jednorazowym lub rzadkim zdarzeniem.

    Jeśli zdecydujesz się na otrzymywanie tokenów sesji i będziesz ich regularnie używać w celu korzystania z usługi Google, Twoja aplikacja internetowa będzie musiała zarządzać miejscem na tokeny, w tym także śledzić użytkownika i usługi Google, dla których token jest ważny. Konta Google nie są skonfigurowane do zarządzania dużą liczbą tokenów i w danym momencie można mieć maksymalnie 10 ważnych tokenów (na użytkownika na aplikację internetową). To ograniczenie umożliwia aplikacji internetowej pobieranie wielu tokenów obejmujących różne usługi, jeśli to konieczne. Nie powoduje też uzyskania nowego tokena za każdym razem, gdy aplikacja internetowa musi uzyskać dostęp do usługi Google. Jeśli zdecydujesz się przechowywać tokeny sesji, powinny być one traktowane tak jak wszystkie inne informacje poufne przechowywane na serwerze.

    Jeśli skonfigurować mechanizm unieważniania tokenów, możesz też regularnie otrzymywać nowe tokeny. Przed wysłaniem prośby o nowy token konieczne będzie unieważnienie istniejącego tokena. W takim przypadku użytkownik będzie musiał się zalogować i przyznać dostęp za każdym razem, gdy zostanie wysłany 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, w jakim stopniu i jaki dostęp ma być udostępniany. Ten dostęp jest wyrażony jako wartość zakresu. Zakres usługi może obejmować prosty adres URL identyfikujący całą usługę lub większy dostęp ograniczony. Niektóre usługi znacznie ograniczają dostęp, na przykład zezwalają na dostęp do ograniczonych informacji. Listę dozwolonych zakresów usług Google, do których chcesz uzyskać dostęp, znajdziesz w dokumentacji tej usługi. Należy zażądać tokena o najwęższym zakresie. Jeśli na przykład chcesz uzyskać dostęp do funkcji 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ń z dużym zakresem.

  4. Skonfiguruj mechanizm, który żąda i otrzymuje token autoryzacji.

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

    Następny URL może zawierać parametry zapytania. Na przykład w przypadku obsługi wielu języków dołącz parametr zapytania identyfikujący wersję aplikacji internetowej wyświetlanej przez użytkownika. Kolejna wartość http://www.yoursite.com/Retrievetoken?Lang=de spowodowałaby przekierowanie http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE. Analizowanie tokena i parametru Lang powoduje, że użytkownik jest przekierowywany do właściwej wersji witryny.

    W pewnych okolicznościach użycie parametru hd może zwiększyć wygodę użytkowników, którzy otrzymają prośbę o dostęp do witryny kont Google. W większości przypadków wystarczy po prostu zalogować się na konto i zdecydować o przyznaniu dostępu. Użytkownicy, którzy mają więcej niż jedno konto Google (standardowe konto Gmail lub co najmniej jedno konto hostowane Google Apps), mogą jednak potrzebować dodatkowej „uniwersalnej procedury logowania”, aby wskazać konto, do którego chcą uzyskać dostęp. Jeśli aplikacja jest przeznaczona do 1 konkretnej domeny zarządzanej, możesz usunąć te dodatkowe kroki, używając tego parametru. Możesz też użyć parametru hd, jeśli aplikacja uzyskuje dostęp do usług, które są niedostępne na kontach hostowanych. Ustawienie wartości „default” (domyślnie) spowoduje ograniczenie tylko do zwykłych kont. Po ustawieniu wartości hd Google automatycznie wybierze odpowiednie konto do autoryzacji.

    Mechanizm tokena musi być wyposażony w możliwość analizowania przekierowania otrzymanego od Google, które zawiera token jednorazowy, i podejmowanie wobec niego działania. Ponieważ tokeny autoryzacji są przypisane do konkretnego użytkownika, aplikacja musi być w stanie powiązać token z użytkownikiem. Preferowaną opcją jest wysłanie pliku cookie do użytkownika przed wysłaniem żądania tokena. Gdy Google przekierowuje użytkownika z powrotem do witryny z dołączonym tokenem, aplikacja może odczytać plik cookie i powiązać go z odpowiednim identyfikatorem użytkownika.

  5. Skonfiguruj mechanizmy, aby w razie potrzeby żądać tokenów sesji i je przechowywać lub unieważniać.

    W zależności od decyzji dotyczących zarządzania tokenami, które zostały wybrane w kroku 2, konieczne może być utworzenie mechanizmów pobierania i unieważniania tokenów sesji (AuthSubSessionToken i AuthSubEndpointToken). Aby przetestować mechanizmy sesji i unieważnień, użyj narzędzia AuthSubTokenInfo, które wskazuje, czy dany token jest prawidłowy. Jeśli przechowujesz tokeny, aplikacja musi śledzić zarówno identyfikator użytkownika, jak i zakres usług.

  6. Skonfiguruj mechanizm wysyłania żądań do usług Google.

    Informacje o prawidłowym formacie żądania znajdziesz w dokumentacji usługi Google. Wszystkie żądania wysyłane do usług Google muszą zawierać prawidłowy token autoryzacji. Zasadniczo żądanie wysyłane do usługi Google ma postać żądania GET HTTP (lub POST w przypadku zapisywania nowych danych) z tokenem wskazanym w nagłówku żądania.

    Nagłówek żądania powinien mieć taką postać:

    Authorization: AuthSub token="token"

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

    Przykład poniżej 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

Aby uzyskać więcej informacji na temat uwierzytelniania AuthSub, w tym rejestrowania aplikacji w Google oraz szczegółowego wyjaśnienia, jak wymienić token jednorazowy na token sesji, zapoznaj się z tymi dodatkowymi zasobami:

Powrót do góry

Autoryzacja ClientLogin

ClientLogin to zastrzeżony interfejs API autoryzacji Google, który jest alternatywą protokołu OAuth w przypadku większości interfejsów API Google. Jeśli to możliwe, nie używaj klienta ClientLogin. Jeśli masz już aplikacje korzystające z ClientLogin, musisz przejść na OAuth lub protokół hybrydowy.

Uwierzytelnianie zainstalowanych aplikacji: ClientLogin

ClientLogin pozwala użytkownikom logować się na konta Google z poziomu aplikacji. Następnie kontaktuje się z Google, podając dane logowania, i prosi o dostęp do określonego interfejsu Google Data API. Po uwierzytelnieniu informacji logowania Google zwraca token, do którego aplikacja będzie odwoływać się za każdym razem, gdy poprosi o dostęp do konta użytkownika, na przykład do pobrania lub opublikowania danych. Token pozostaje ważny przez określony czas zdefiniowany w dowolnej usłudze Google, z którą współpracujesz.

Uwaga: biblioteki klienta interfejsów API danych Google udostępniają metody ułatwiające korzystanie z ClientLogin w zainstalowanych aplikacjach. Konkretnie chodzi o metody uzyskiwania tokena uwierzytelniania, obsługi testów CAPTCHA, wycofywania tokena uwierzytelniania do późniejszego użycia oraz wysyłania poprawnego nagłówka Authorization z każdym żądaniem. Jeśli używasz jednej z bibliotek, zobacz Używanie klienta ClientLogin z bibliotekami klienta interfejsów API danych Google.

Proces autoryzacji ClientLogin

Autoryzacja przy użyciu ClientLogin obejmuje sekwencję interakcji między 3 elementami: zainstalowaną aplikacją, usługami Google i użytkownikami. Ten diagram pokazuje sekwencję:

Proces autoryzacji

  1. Gdy aplikacja innej firmy musi uzyskać dostęp do usługi Google użytkownika, pobiera nazwę logowania i hasło użytkownika.
  2. Aplikacja innej firmy następnie wysyła wywołanie ClientLogin do usługi autoryzacji Google.
  3. Jeśli usługa autoryzacji Google zdecyduje, że konieczna jest dodatkowa weryfikacja, zwróci odpowiedź o niepowodzeniu za pomocą tokena i testu CAPTCHA w postaci adresu URL obrazu CAPTCHA.
  4. Jeśli otrzymasz test CAPTCHA, aplikacja innej firmy wyświetla obraz CAPTCHA dla użytkownika i prosi o odpowiedź.
  5. Jeśli pojawi się taka prośba, użytkownik przesyła odpowiedź na pytanie CAPTCHA.
  6. Aplikacja innej firmy utworzy nowe wywołanie ClientLogin, w tym odpowiedź CAPTCHA i token (otrzymane z odpowiedzią o niepowodzeniu).
  7. Po udanej próbie logowania (z testem CAPTCHA) lub bez niego usługa autoryzacji Google zwraca token do aplikacji.
  8. Aplikacja kontaktuje się z usługą Google, prosząc o dostęp do danych, podając token otrzymany z usługi Google Authorization.
  9. Jeśli usługa Google rozpozna token, dostarcza żądany dostęp do danych.

Przy użyciu ClientLogin

Za pomocą tego interfejsu w zainstalowanej aplikacji możesz automatycznie uzyskiwać dostęp do konta Google użytkownika. Po zebraniu informacji logowania od użytkownika wywołaj klienta ClientLogin, aby poprosić o dostęp do konta użytkownika. Po uwierzytelnieniu informacji logowania Google zwraca token, do którego aplikacja będzie odwoływać się za każdym razem, gdy poprosi o dostęp do konta użytkownika. Token pozostaje ważny przez określony czas, który jest określany przez dowolną z usług Google, z którą współpracujesz.

Wbudowanie ClientLogin w aplikację wymaga wykonania tych czynności:

  1. Utwórz element interfejsu, aby rejestrować dane logowania użytkownika.

    Interfejs musi pobierać nazwę użytkownika (adres e-mail i domenę) oraz hasło. Interfejs powinien również umożliwiać wyświetlanie obrazu CAPTCHA z adresu URL otrzymanego od Google (jeśli jest on wymagany) i proszenia użytkownika o prawidłową odpowiedź. Najlepiej, jeśli w interfejsie użytkownika znajduje się link do strony logowania na konto Google („https://www.google.com/accounts/Login”), jeśli użytkownik musi zarejestrować nowe konto lub wykonać inne czynności konserwacyjne.

  2. Napisz kod, aby wygenerować prawidłowo sformułowane żądanie HTTPS POST ClientLogin i je przesłać.

    Kod ten musi zawierać obiekty logiczne (obsługujące test CAPTCHA) oraz parametry logintoken i logincaptcha. Powinno być również możliwe wykrycie błędu, gdy użytkownik pominie wymagane informacje, lub powtórzenie nieprawidłowych danych po nieudanej próbie zalogowania się, a także wyświetlenie błędu bez zbędnego żądania.

  3. Obsługuj odpowiedzi od Google.

    Istnieją 4 możliwe odpowiedzi na żądanie logowania:

    • powodzenie (HTTP 200),
    • Błąd (HTTP 403) z wyjaśnieniem kodu błędu
    • nieprawidłowe żądanie, zwykle spowodowane nieprawidłowym żądaniem
    • nieudana próba CAPTCHA

    Odpowiedź powodzenia zawiera token autoryzacji oznaczony etykietą „Auth”. Ten token musi być widoczny we wszystkich kolejnych żądaniach wysyłanych do usługi Google z tego konta. Tokeny autoryzacji powinny być ściśle zabezpieczone i nie należy ich przekazywać do żadnej innej aplikacji, ponieważ reprezentują one dostęp do konta użytkownika. Limit czasu tokena zależy od usługi, do której go wydał.

    Odpowiedź o niepowodzeniu zawiera co najmniej jeden kod błędu oraz URL z komunikatem o błędzie, który może być wyświetlany użytkownikowi. Pamiętaj, że ClientLogin nie rozróżnia błędów z powodu nieprawidłowego hasła ani hasła z nierozpoznanej nazwy użytkownika (np. jeśli użytkownik nie zarejestrował konta). Aplikacja musi odpowiednio obsługiwać wszystkie możliwe komunikaty o błędach.

    Odpowiedź z komunikatem o błędzie CAPTCHA oznacza, że z jakiegokolwiek powodu podjęto dodatkowe środki bezpieczeństwa. Ta odpowiedź jest łączona z adresem URL obrazu CAPTCHA i tokenem reprezentującym konkretne zadanie CAPTCHA.

  4. Wykonaj zadanie CAPTCHA od Google.

    Aby wykonać test zabezpieczający, aplikacja musi wyświetlać obraz CAPTCHA i uzyskać odpowiedź użytkownika. Aby wyświetlić obraz CAPTCHA, użyj wartości CaptchaUrl zwróconej z odpowiedzią błędu, poprzedzając go adresem 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 autoryzowaniem dostępu do konta.

    Deweloperzy, którzy nie chcą zarządzać procesem pobierania i przesyłania odpowiedzi CAPTCHA użytkownika, mogą to robić. W odpowiedzi na test CAPTCHA aplikacja może kierować użytkownika na stronę hostowaną przez Google: „https://www.google.com/accounts/DisplayUnlockCaptcha”. Gdy użytkownik odpowie na test zabezpieczający, serwer Google ufa używanemu komputerowi. Aplikacja może następnie ponownie wysłać pierwotne żądanie logowania, aby uzyskać token autoryzacji.

    5. Uwaga: nie przeprowadzamy próby zalogowania się przed CAPTCHA. Oznacza to, że próba logowania CAPTCHA nie powiodła się.

* CAPTCHA to znak towarowy Uniwersytetu Carnegie Mellon

Powrót do góry

Uwierzytelnianie gadżetów

Serwer proxy OAuth

Jeśli tworzysz gadżet za pomocą standardowego interfejsu API do tworzenia gadżetów, możesz uzyskać dostęp do funkcji platformy OAuth zwanej serwerem proxy OAuth, która zapewnia dostęp do interfejsów API danych Google. Protokół OAuth (opisany powyżej) to standard uwierzytelniania, który umożliwia użytkownikom dostęp do ich prywatnych danych w usłudze hostingowej gadżetów, takiej jak iGoogle, MySpace lub orka, lub udostępnianie ich w innej witrynie lub gadżecie. Serwer proxy OAuth został zaprojektowany tak, aby ułatwić programistom tworzenie gadżetów przez ukrywanie wielu szczegółów uwierzytelniania OAuth. Serwer proxy działa w ramach projektu open source o nazwie Shindig, który jest implementacją specyfikacji gadżetu.

Uwaga: serwer OAuth obsługuje tylko gadżety korzystające z interfejsu API gadgets.* i działające w kontenerach OpenSocial. Nie obsługuje on starszego interfejsu API gadżetów.

Proces uwierzytelniania

Gadżet musi uzyskać token OAuth, aby uzyskać dostęp do danych użytkownika. Serwer proxy OAuth zarządza przepływem uwierzytelniania. Gdy użytkownik po raz pierwszy zainstaluje Twój gadżet, wykonywana jest ta procedura:

  1. Gadżet wczytuje się po raz pierwszy i próbuje uzyskać dostęp do danych użytkownika za pomocą jednego z interfejsów API danych Google.
  2. Żądanie nie zostało zrealizowane, ponieważ użytkownik nie przyznał dostępu. Obiekt odpowiedzi zawiera adres URL (w polu response.oauthApprovalUrl) strony zatwierdzania OAuth. Gadżet powinien udostępniać metodę uruchamiania nowego okna z tym adresem URL.
  3. Na stronie zatwierdzania użytkownik może przyznać lub odrzucić dostęp do Twojego gadżetu. W przypadku powodzenia użytkownik trafia na podaną przez Ciebie stronę oauth_callback. Aby zapewnić użytkownikom jak najlepsze wrażenia, skorzystaj z http://oauth.gmodules.com/gadgets/oauthcallback.
  4. Następnie użytkownik zamyka wyskakujące okienko. Aby poinformować gadżet, że użytkownik go zatwierdził, możesz użyć modułu obsługi wyskakujących okienek, aby wykryć zamknięcie ekranu. Możesz też wyświetlić link do swojego gadżetu (np. „Uprawnienia zostały zatwierdzone”), które użytkownik może kliknąć po zamknięciu tego okna.
  5. Gadżet ponownie próbuje uzyskać dostęp do interfejsu Google Data API, wysyłając żądanie danych użytkownika. Ta próba się powiodła.
  6. Twój gadżet został uwierzytelniony i może normalnie działać.

Konfiguracja gadżetu

Aby uzyskać dostęp do interfejsów API danych Google, musisz najpierw poprosić gadżet, aby używał protokołu OAuth jako metody uwierzytelniania. Dodaj element <OAuth> w sekcji <ModulePrefs> kodu 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 zmień tylko te parametry zapytania:

scope
Wymagany parametr w adresie URL żądania. Twój gadżet może uzyskać dostęp do danych z zakresu scope używanych w tym parametrze. W tym przykładzie gadżet może uzyskać dostęp do danych z Bloggera i Kalendarza. Gadżet może zażądać danych dla pojedynczego zakresu lub wielu zakresów, tak jak w tym przykładzie.
oauth_callback
Opcjonalny parametr w adresie URL autoryzacji. Strona zatwierdzenia OAuth przekierowuje na ten adres URL, gdy użytkownik zatwierdzi dostęp do danych. Wartość tego parametru powinna wynosić http://oauth.gmodules.com/gadgets/oauthcallback, by użytkownicy mogli zainstalować gadżet. Ta strona zawiera fragment kodu JavaScript, który automatycznie zamyka wyskakujące okienko. Możesz też ustawić ten parametr tak, aby wskazywał własną „zatwierdzoną” stronę, lub pozostawić go pusty.

Dostęp do uwierzytelnionego pliku danych interfejsu Google Data API

Po uwierzytelnieniu użytkownika w gadżecie dostęp do interfejsu Google Data API jest prosty i dostępny w bibliotece klienta JavaScript interfejsów API danych Google. Informacje o używaniu biblioteki na serwerze proxy OAuth znajdziesz w artykule Używanie biblioteki klienta JavaScript.

Więcej informacji o gadżetach

Pełne informacje na temat tworzenia gadżetów interfejsu Google Data API, w tym szczegóły dotyczące serwera proxy OAuth, artykuł o tym, jak zacząć, i specyfikację gadgets.*, znajdziesz w tych dodatkowych zasobach:

Powrót do góry