Конфигурирајте ги двата влеза за транспорт кога HTTP повиците на Firebase и освежувањето на акредитивите треба да го користат истиот прокси. Јавна HTTP крајна точка избрана од списокот со HTTP прокси бара истиот пар предавања:

var proxy = new java.net.Proxy(
    java.net.Proxy.Type.HTTP,
    new java.net.InetSocketAddress("proxy.example.net", 8080));

var transport =
    new com.google.api.client.http.javanet.NetHttpTransport.Builder()
        .setProxy(proxy)
        .build();

var credentials = com.google.auth.oauth2.GoogleCredentials.fromStream(
    serviceAccountStream, () -> transport);

var options = com.google.firebase.FirebaseOptions.builder()
    .setCredentials(credentials)
    .setHttpTransport(transport)
    .build();

var app = com.google.firebase.FirebaseApp.initializeApp(options);

Двете важни предавања се fromStream(serviceAccountStream, () -> transport) и setHttpTransport(transport). Првото го обезбедува HTTP транспортот за добивање пристапни токени; второто го обезбедува HTTP транспортот на апликацијата Firebase. Поставувањето само на едното може да го остави другото на неговата стандардна рута.

serviceAccountStream е доверливиот тек на акредитиви на сервисната сметка на апликацијата. Задржете ја апликацијата за нејзиниот работен товар и ослободете ја преку вообичаениот животен циклус на Firebase. Поставката за прокси го остава името на одредишниот домаќин недопрено за TLS проверка; не бара ниту замена на SDK класи, ниту SSL фабрика што верува на сè.

Опсегот овде се прикажаните HTTP интерфејси. Работен товар што користи WebSocket на Realtime Database или друг сервисен транспорт бара одделно проверување на поддршката за рутирање на тој транспорт.

Поврзани статии