Autoryzacja identyfikatora klienta klienta

Ważne: abonament Google Maps Platform Premium nie jest już dostępny dla nowych klientów ani osób, które chcą się zarejestrować.

Uwierzytelnianie za pomocą identyfikatora klienta Maps JavaScript API

Możesz uwierzytelniać swoje żądania w Google Maps Platform za pomocą identyfikatora klienta w połączeniu z rejestracją adresu URL (zamiast klucza interfejsu API).

Podczas wczytywania interfejsu API podawaj identyfikator klienta

Poniżej znajdziesz kod, który pokazuje, jak zastąpić YOUR_CLIENT_ID własnym identyfikatorem klienta podczas wczytywania Google Maps Platform.

<script async defer src="https://maps.googleapis.com/maps/api/js?client=YOUR_CLIENT_ID&v=quarterly&callback=initMap"></script>

Zarządzanie autoryzowanymi adresami URL

Aby uniemożliwić osobom trzecim korzystanie z Twojego identyfikatora klienta na ich stronie internetowej, dostęp do niego jest ograniczony do listy adresów URL, które zostały przez Ciebie autoryzowane.

Znajdowanie identyfikatora klienta w konsoli Cloud

Autoryzacja URL w konsoli Cloud

  • Wszystkie autoryzowane URL-e są wymienione w tabeli Autoryzowane URL-e dla identyfikatora klienta gme-[company] na stronie Identyfikator klienta.

  • Aby usunąć adres URL, zaznacz pole po lewej stronie adresu URL i w prawym górnym rogu tabeli kliknij ikonę  usuwania.

  • Aby dodać nowe adresy URL, u dołu tabeli kliknij Dodaj adresy URL.

Ważne: zasady dotyczące adresów URL autoryzowanych identyfikatorów klienta różnią się od ograniczeń dotyczących odesłania przez klucz API. Więcej informacji znajdziesz poniżej.

W przypadku autoryzowanych adresów URL należy wziąć pod uwagę te kwestie:

Nazwa domeny ani adres IP nie muszą być dostępne publicznie.
Przykłady prawidłowych wpisów: http://myintranet i http://192.168.1.1.
Autoryzowane są też wszystkie subdomeny określonej domeny.

Jeśli na przykład domena http://example.com jest autoryzowana, to autoryzowana jest też subdomena http://www.example.com. Odwrotna zależność nie jest prawdziwa: jeśli http://www.example.com ma uprawnienia, http://example.com nie ma ich automatycznie.

Wszystkie ścieżki podrzędne ścieżki autoryzowanej są również autoryzowane.

Jeśli na przykład http://example.com ma uprawnienia, http://example.com/foo też je ma. Ponieważ subdomeny określonej domeny są też autoryzowane, http://sub.example.com/bar jest autoryzowana.

W ścieżkach wielkość liter ma znaczenie.

Na przykład http://www.example.com/ThisPath/ to nie to samo, co http://www.example.com/thispath/.

Możesz ograniczyć prawidłowe adresy URL do tych, które używają określonych portów.

Jeśli na przykład podano wartość http://example.com:8080/foo, nie oznacza to autoryzacji wartości http://example.com.

Protokoły HTTP i HTTPS są uważane za różne adresy URL.

Jeśli na przykład https://example.com jest autoryzowany, http://example.com nie jest automatycznie autoryzowany.

Jeśli podasz odwołanie do sufiksu bez schematu protokołu, np. www.example.com, zostaną utworzone osobne reguły dla HTTP i HTTPS.

Aby uzyskać informacje o bardziej egzotycznych schematach protokołów niż HTTP czy HTTPS, zapoznaj się z instrukcjami w Cloud Console.