Autoryzacja identyfikatora klienta klienta

Ważne: abonament Premium Google Maps Platform nie jest już dostępny dla do rejestracji lub nowych klientów.

Uwierzytelnianie identyfikatora klienta Maps JavaScript API

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

Określanie identyfikatora klienta podczas wczytywania interfejsu API

Poniższy kod 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ć firmie zewnętrznej korzystanie z Twojego identyfikatora klienta w swojej witrynie, tag identyfikatora klienta można użyć tylko w przypadku adresów URL .

Znajdowanie identyfikatora klienta w konsoli Cloud

Autoryzacja adresu URL w konsoli Cloud

  • Autoryzowane adresy URL wymienione są w Tabela Autoryzowane adresy URL dla identyfikatora klienta gme-[company] w tabeli Strona identyfikatora klienta.

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

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

Inportant: reguły dotyczące adresów URL autoryzowanych identyfikatorów klientów różnią się od reguł odsyłających do klucza interfejsu API ograniczeń. Poniżej podajemy dalsze szczegóły.

Autoryzowani adresy URL obowiązują te zasady:

Nazwa domeny lub adres IP nie muszą być publicznie dostępne.
Na przykład http://myintranet i http://192.168.1.1 są prawidłowymi wpisami.
Wszystkie subdomeny określonej domeny również są autoryzowane.

Jeśli na przykład autoryzowana jest sama domena http://example.com, ciąg subdomena http://www.example.com również jest autoryzowana. Na odwrót nieprawda: jeśli http://www.example.com jest autoryzowany, http://example.com nie jest automatycznie autoryzowany.

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

Jeśli na przykład http://example.com jest autoryzowany, ciąg http://example.com/foo również ma autoryzację. Ponadto, ponieważ subdomeny z określonej domeny też są autoryzowane, więc http://sub.example.com/bar jest .

W ścieżkach rozróżniana jest wielkość liter.

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

Możesz ograniczyć działanie prawidłowych adresów URL do tych, które korzystają z określonych portów.

Jeśli na przykład określono http://example.com:8080/foo, który nie autoryzuje aplikacji http://example.com.

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

Jeśli na przykład https://example.com ma autoryzację, http://example.com to nie autoryzowano automatycznie.

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

Bardziej egzotyczne schematy protokołów niż HTTP i HTTP znajdziesz w w Cloud Console.