JavaクラウドエンドポイントのハードコードされたクライアントIDとuseDatastoreForAdditionalConfigの使用

Question

Javaクライアントを使用してGoogle Cloud Endpoint APIにクライアントIDのハードコードに関する質問があります。

特定のプロジェクトに関連付けられたクライアントIDを持つ複数のプロジェクトがあり、プロジェクト固有のGAEアーチファクト（WAR）を作成する必要があることが判明しました。これは、マイクロサービスアーキテクチャを使用しており、アーチファクトのコンビナトリアルな爆発が存在するため、理想的ではありません。

環境に依存しないアーチファクトを作成しようとすると、APIの機能が文書化されていないので、useDatastoreForAdditionalConfigという属性が使用されています。

ではなく、以下の、説明するために：

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

は、我々は使用します。私たちはこの機能を聞いたことがあるしかし

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

は、今後のリリースで廃止されます。私の疑問は、私たちが人工物を作る方法に何か間違っているのだろうか？ Googleのビルドプロセスに何も問題がなければ、Googleはこれを問題として認識していますか？Javaでプロジェクトに依存しないGAEアーチファクトを作成する計画はありますか？

Answer 1

@ saiyrからの指導の後、私たちはこの問題の解決策を思いつき、答えを共有することが役立つだろうと考えました。

私たちは、次の手順を実行して、枠組みの中で、クライアントのIDアサーションをバイパスしています

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

残念ながら、この状況を処理するための良い方法はありません。

注：許可のClientIDをビルド 時に指定する必要があるため、再構築し、追加や は、クライアントIDや観客の任意のクライアントIDを変更した後、あなたのAPIのバックエンドを再デプロイする必要がありますGoogleドキュメントは明らかに限界をhere言及しています。 （また は AndroidのクライアントのためにあなたのAndroidのプロジェクトのために再生されたjarファイルを更新するとiOS クライアントのためのObjective-Cライブラリを再生成する必要があります。）

あなたは、外部化のClientIDを持つ単一のアーティファクトを持つことはできません。しかし、あなたはプラグインを使ってclientIdsを更新するプロセスを自動化することができます。replacer