Prüfen Sie, ob der Tables-Builder eine vollständige HTTP-Pipeline erhält. Diese Eingabe überschreibt seine separate httpClient-Option; wenn die Anwendung eine Pipeline besitzt, konfigurieren Sie den proxyfähigen Transport beim Aufbau dieser Pipeline.

Für die direkte Netty-HTTP-Client-Eingabe erstellen Sie den Transport und übergeben ihn an 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 ist hier com.azure.core.http.HttpClient. Die übrigen Typen stammen aus Azure Core HTTP/Netty, Azure Data Tables und java.net.InetSocketAddress. Die Anwendung liefert die Konfigurations- und Anmeldeinformationsvariablen.

ProxyOptions.Type.HTTP wählt den Vermittler; setCredentials liefert dessen Konto und kann für Endpunkte ohne Authentifizierung entfallen. In dieser Konfiguration kann ein Eintrag aus einer HTTP-Proxy-Liste die Adresse für eine zulässige öffentliche Tables-Endpunktroute liefern; lassen Sie keine Proxy-Anmeldeinformationen am Transport. Die Speicherverbindungszeichenfolge wählt weiterhin den Tables-Dienst.

Dies verwendet die Authentifizierung per Verbindungszeichenfolge. Eine Identitätsanordnung kann einen separaten HTTP-Client für die Token-Beschaffung haben, dessen Route ebenfalls konfiguriert werden muss.

Ähnliche Artikel