Google Cloud Endpoints fest codierte Client-ID in Java und die Verwendung von useDatastoreForAdditionalConfig

Question

Ich habe eine Frage bezüglich der fest codierten Art von Client-IDs in Google Cloud Endpoint API mit Java.

Wir haben mehrere Projekte mit Client-IDs an bestimmte Projekte gebunden und haben festgestellt, dass wir projektspezifische GAE Artefakte (WARs) erstellen müssen. Dies ist eine weniger als ideale Situation, da wir eine Micro-Services-Architektur verwenden und es wird eine kombinatorische Explosion von Artefakten geben.

In einem Versuch, ein agnostisches Artefakt zu erstellen, haben wir ein schlecht dokumentiertes Feature der API verwendet, das useDatastoreForAdditionalConfig Attribut.

Zur Veranschaulichung statt der folgenden Möglichkeiten:

@Api(
    name = "example", 
    version = "v1", 
    scopes = { "example-scope" }, 
    clientIds = { "example-client-id" }, 
) 

Wir verwenden:

@Api(name = "example", 
     version = "v1", 
     useDatastoreForAdditionalConfig = AnnotationBoolean.TRUE 
) 

aber wir diese Funktion gehört haben, wird in einer kommenden Version veraltet sein. Meine Frage wäre, gibt es etwas falsch in der Art, wie wir unsere Artefakte bauen? Auch wenn an unserem Build-Prozess nichts falsch ist, erkennt Google dies als ein Problem an und hat er einen Plan, um die Erstellung von projektunabhängigen GAE-Artefakten in Java zu ermöglichen?

Answer 1

Nach ein paar Anweisungen von @saiyr haben wir eine Lösung für dieses Problem gefunden und fanden es hilfreich, die Antwort zu teilen.

Wir Client-ID Behauptungen im Rahmen umgangen haben, indem Sie folgendermaßen vorgehen:

import com.google.api.server.spi.Constant; 
import com.google.api.server.spi.auth.GoogleOAuth2Authenticator; 

@Api(
    name = "example", 
    version = "v1", 
    scopes = { Constant.API_EMAIL_SCOPE }, 
    clientIds = { Constant.SKIP_CLIENT_ID_CHECK }, 
    authenticators = { ClientIdAuthenticator.class,GoogleOAuth2Authenticator.class } 
) 

Dann haben wir eine benutzerdefinierte Authentifikator, die von der programmatischen Aussage des Kunden-ID kümmerten:

public class ClientIdAuthenticator implements Authenticator { 
    @Override 
    public User authenticate(HttpServletRequest httpServletRequest) { 
    // Lookup config from cloud datastore for requestURI 
    OAuthService service = OAuthServiceFactory.getOAuthService(); 
    String clientId = service.getClientId(Constant.API_EMAIL_SCOPE); 
    // Assert clientId contained in datastore configuration 
    } 
} 

Answer 2

Leider gibt es keinen besseren Weg, diese Situation zu bewältigen. Google Text & Tabellen erwähnt deutlich die Grenzen here:

Hinweis: Da die autorisierten clientIds bei Build Zeit angegeben werden müssen, müssen Sie neu erstellen und erneut bereitstellen Ihre API-Backend nach dem Hinzufügen oder alle Client-IDs in clientIds oder das Publikum zu verändern. (Sie müssen auch aktualisieren das regenerierte JAR-Datei für Ihr Android-Projekt für ein Android-Client und regenerieren die Objective-C-Bibliothek für iOS -Clients.)

Sie können nicht ein einziges Artefakt mit externalisierte clientIds haben. Aber, Sie könnten den Prozess der Aktualisierung der Client-IDs mit maven replacer Plugin automatisieren.