השתמשו בתעבורת פרוקסי אחת עבור Firebase Admin Java ורענון אסימונים

הגדירו את שתי קלטות התעבורה כאשר קריאות ה-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 או בתעבורת שירות אחרת צריך בדיקה נפרדת של תמיכת הניתוב של אותה תעבורה.