Azure Notification Hubs .NET: kiu proksea agordo venkas?

Agordu NotificationHubSettings.Proxy aŭ liveritan HTTP-transporton, konsiderante la prioritaton de HttpClient kaj MessageHandler en la konstruilo.

En la Notification Hubs .NET API kun NotificationHubSettings, prokseo povas esti liverita dum la konstruado de la kliento:

var settings = new Microsoft.Azure.NotificationHubs.NotificationHubSettings
{
    Proxy = new System.Net.WebProxy("http://proxy.example:8080")
};
var hub = new Microsoft.Azure.NotificationHubs.NotificationHubClient(
    hubConnectionString, hubName, settings);

La konekta ĉeno kaj la huba nomo restas la servo-agordo. Publika HTTP-finpunkto el la listo de HTTP-prokseoj povas plenigi la WebProxy-adreson en la implicita konstruvojo.

Ekzistas ordoregulo en tiu konstruilo:

  1. Liverita HttpClient estas uzata unue.
  2. Alie, liverita MessageHandler kreas la HTTP-klienton.
  3. Alie, Proxy kreas HttpClientHandler agorditan por prokseo.
  4. Se nenio estas liverita, la konstruilo kreas sian implicitan HTTP-klienton.

Se la aplikaĵo jam liveras HttpClient aŭ MessageHandler, agordu la prokseon de tiu transporto anstataŭ atendi, ke la aparta eco Proxy superregos ĝin.

Por proksea konto, agordu akreditaĵojn sur la WebProxy antaŭ konstruado. Ili aŭtentikas al la peranto, ne al la Notification Hub.

Pli malnovaj ekzemploj nomas NotificationHubClientSettings. Kongruigu la agordan tipon kaj konstruilon, kiujn elmetas la instalita pakaĵo, anstataŭ miksi tiun nomon en API-on, kiu atendas NotificationHubSettings.

Rilataj artikoloj