Autoryzacja identyfikatora klienta klienta

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

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 podczas wczytywania Google Maps Platform zastąpić YOUR_CLIENT_ID własnym identyfikatorem klienta.

<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ętrzne używanie Twojego identyfikatora klienta w swojej witrynie, musisz używać identyfikatora klienta tylko do listy adresów URL, które zostały przez Ciebie specjalnie autoryzowane.

Znajdowanie identyfikatora klienta w konsoli Cloud

Autoryzacja adresu URL w konsoli Cloud

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

  • Aby usunąć adres URL, zaznacz pole po jego lewej stronie, a następnie w prawym górnym rogu tabeli kliknij ikonę usuń.

  • 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 ograniczeń dotyczących stron odsyłających klucza interfejsu API. 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, autoryzowana jest też subdomena http://www.example.com. I nie w drugą stronę – jeśli http://www.example.com ma autoryzację, http://example.com nie ma autoryzacji automatycznie.

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

Jeśli na przykład autoryzowana jest właściwość http://example.com, też http://example.com/foo również ma prawo. Autoryzują się też subdomeny określonej domeny, więc autoryzacją ma http://sub.example.com/bar.

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, nie oznacza to autoryzacji 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 nie jest autoryzowana automatycznie.

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

Bardziej egzotyczne schematy protokołów niż HTTP i HTTP znajdziesz w instrukcjach dostępnych w konsoli Cloud.