Autorisierung mit Client-ID und URL

Wichtig: Sie können sich nicht mehr für die Google Maps Platform-Premiumoption registrieren. Auch für Neukunden ist sie nicht mehr verfügbar.

Maps JavaScript API: Client-ID-Authentifizierung

Anstatt einen API-Schlüssel zu verwenden, können Sie Ihre Google Maps Platform-Anfragen auch mit einer Kombination aus Client-ID und URL-Registrierung authentifizieren.

Beim Laden der API eine Client-ID angeben

Im folgenden Codebeispiel sehen Sie, wie Sie beim Laden der Google Maps Platform YOUR_CLIENT_ID durch Ihre eigene Client-ID ersetzen.

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

Autorisierte URLs verwalten

Um zu verhindern, dass Dritte Ihre Client-ID auf ihrer eigenen Website verwenden, ist die Nutzung Ihrer Client-ID auf eine Liste von URLs beschränkt, die Sie explizit autorisiert haben.

Client-ID in der Cloud Console finden

URL-Autorisierung in der Cloud Console

  • Alle autorisierten URLs sind auf der Seite mit der Client-ID in der Tabelle der autorisierten URLs für die Client-ID für gme-[Unternehmen] aufgeführt.

  • Wenn Sie eine URL entfernen möchten, klicken Sie auf das Kästchen links daneben und dann rechts oben in der Tabelle auf das Symbol zum Löschen.

  • Sie können neue URLs hinzufügen, indem Sie am Ende der Tabelle auf URLs hinzufügen klicken.

Wichtig: Die Regeln für autorisierte Client-ID-URLs unterscheiden sich von den Einschränkungen in Bezug auf API-Schlüssel-Referrer-URLs. Mehr dazu erfahren Sie weiter unten.

Hinsichtlich autorisierter URLs ist Folgendes zu beachten:

Der Domainname oder die IP-Adresse muss nicht öffentlich zugänglich sein.
So sind beispielsweise http://myintranet und http://192.168.1.1 gültige Einträge.
Alle Subdomains einer angegebenen Domain sind ebenfalls autorisiert.

Wenn beispielsweise die Grunddomain http://example.com autorisiert ist, gilt das auch für die Subdomain http://www.example.com. Umgekehrt ist das nicht der Fall: Wenn http://www.example.com autorisiert ist, trifft dies für http://example.com nicht automatisch zu.

Alle untergeordneten Pfade eines autorisierten Pfades sind ebenfalls autorisiert.

Beispiel: Wenn http://example.com autorisiert ist, trifft das auch für http://example.com/foo zu. Zusätzlich gilt: Da Subdomains einer angegebenen Domain ebenfalls eingeschlossen sind, ist auch http://sub.example.com/bar autorisiert.

Bei Pfaden wird zwischen Groß- und Kleinschreibung unterschieden.

Beispielsweise gelten http://www.example.com/ThisPath/ und http://www.example.com/thispath/ als zwei unterschiedliche Pfade.

Sie können gültige URLs auf bestimmte Ports beschränken.

Wenn beispielsweise http://example.com:8080/foo angegeben ist, wird http://example.com hierdurch nicht autorisiert.

URLs, die das HTTP-Protokoll verwenden, und solche, die das HTTPS-Protokoll nutzen, gelten als unterschiedliche URLs.

Wenn beispielsweise https://example.com autorisiert ist, gilt das nicht automatisch auch für http://example.com.

Falls Sie eine Suffixreferenz ohne Protokollschema angeben, zum Beispiel www.example.com, werden separate Regeln für HTTP und HTTPS erstellt.

Informationen zu anderen Protokollschemas finden Sie unter der entsprechenden Anleitung in der Cloud Console.