ProxyOptions של Azure Java Netty עבור לקוח Tables

בנו תעבורת Netty HTTP מאומתת והעבירו אותה לבונה לקוח Azure Tables.

בדקו אם בונה Tables מקבל צינור HTTP מלא. קלט זה עוקף את האפשרות httpClient הנפרדת שלו; אם היישום מחזיק בצינור, הגדירו את התעבורה מודעת ה-proxy בזמן בניית אותו צינור.

לקלט ישיר של לקוח Netty HTTP, בנו את התעבורה והעבירו אותה ל-Tables:

ProxyOptions proxy = new ProxyOptions(
    ProxyOptions.Type.HTTP,
    new InetSocketAddress("proxy.example.net", 8080)
);
proxy.setCredentials(proxyUser, proxyPassword);

HttpClient transport = new NettyAsyncHttpClientBuilder()
    .proxy(proxy)
    .build();

TableClient tables = new TableClientBuilder()
    .connectionString(storageConnectionString)
    .tableName("records")
    .httpClient(transport)
    .buildClient();

HttpClient כאן הוא com.azure.core.http.HttpClient. הסוגים האחרים מגיעים מ-Azure Core HTTP/Netty, ‏Azure Data Tables ו-java.net.InetSocketAddress. היישום מספק את משתני התצורה והאישורים.

ProxyOptions.Type.HTTP בוחר את המתווך; setCredentials מספק את החשבון שלו וניתן להשמיטו עבור נקודות קצה ללא אימות. בתצורה זו, רשומה מרשימת פרוקסי HTTP יכולה לספק את הכתובת עבור מסלול נקודת קצה ציבורית מורשית של Tables; אל תשאירו אישורי פרוקסי בתעבורה. מחרוזת החיבור של האחסון עדיין בוחרת את שירות Tables.

זה משתמש באימות באמצעות מחרוזת חיבור. סידור אישורי זהות יכול לכלול לקוח HTTP נפרד לרכישת אסימון, וגם המסלול שלו צריך להיות מוגדר.

מאמרים קשורים