Autorisierung mit Client-ID und URL

Wichtig: Du kannst dich 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, kannst du deine Google Maps Platform-Anfragen auch mit einer Kombination aus einer Client-ID und einer URL-Registrierung authentifizieren.

Beim Laden der API eine Client-ID angeben

Anhand des folgenden Codes siehst du, wie du YOUR_CLIENT_ID beim Laden der Google Maps Platform durch deine eigene Client-ID ersetzen kannst.

<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 deine Client-ID durch Dritte auf deren eigener Website verwendet wird, ist die Nutzung deiner Client-ID auf eine Liste von URLs beschränkt, die von dir eigens autorisiert wurden.

Client-ID in der Cloud Console ermitteln

URL-Autorisierung in der Cloud Console

  • Alle autorisierten URLs findest du auf der Client-ID-Seite in der Tabelle mit den autorisierten URLs für die Client-ID für gme-[Unternehmen].

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

  • Du kannst neue URLs hinzufügen, indem du am Ende der Tabelle auf URLs hinzufügen klickst.

Wichtig: Die Regeln für autorisierte Client-ID-URLs unterscheiden sich von den Einschränkungen in Bezug auf API-Schlüssel-Verweis-URLs. Noch mehr Details erhältst du 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 hingegen 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.

Du kannst 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 du eine Suffixreferenz ohne Protokollschema bereitstellst, zum Beispiel www.example.com, werden separate Regeln für HTTP und HTTPS erstellt.

Informationen zu anderen Protokollschemas findest du unter den entsprechenden Anleitungen in der Cloud Console.