Налаштуйте обидва входи транспорту, коли HTTP-виклики Firebase й оновлення облікових даних мають використовувати той самий proxy. Публічна HTTP-точка, вибрана зі списку HTTP-proxy, потребує тієї самої пари передач:

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. Налаштування proxy залишає ім'я хоста призначення незмінним для перевірки TLS; воно не потребує заміни класів SDK чи SSL-фабрики, що довіряє всьому.

Обсяг тут — показані HTTP-інтерфейси. Навантаження, що використовує Realtime Database WebSocket або інший транспорт сервісу, потребує окремої перевірки підтримки маршрутизації цього транспорту.

Схожі статті