Կարգավորեք transport-ի երկու մուտքերն էլ, երբ Firebase-ի HTTP կանչերը և հավատարմագրերի թարմացումը պետք է օգտագործեն նույն proxy-ն։ HTTP proxy-ների ցանկից ընտրված հանրային 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 transport-ը՝ մուտքի token-ներ ստանալու համար, երկրորդը՝ Firebase հավելվածի HTTP transport-ը։ Միայն մեկը սահմանելը կարող է մյուսին թողնել իր լռելյայն ուղու վրա։

serviceAccountStream-ը հավելվածի վստահելի սպասարկման հաշվի հավատարմագրերի հոսքն է։ Պահեք հավելվածը իր աշխատանքային ծանրաբեռնվածության համար և թողարկեք այն Firebase-ի սովորական կյանքի ցիկլով։ Proxy-ի կարգավորումը թողնում է նպատակակետի hostname-ը անփոփոխ TLS ստուգման համար․ այն չի պահանջում ոչ SDK դասերի փոխարինում, ոչ էլ ամեն ինչի վստահող SSL ֆաբրիկա։

Այստեղ շրջանակը ցուցադրված HTTP ինտերֆեյսներն են։ Realtime Database-ի WebSocket կամ այլ ծառայության transport օգտագործող ծանրաբեռնվածությունը պահանջում է այդ transport-ի երթուղավորման աջակցության առանձին ստուգում։

Առնչվող հոդվածներ