.NET-Anwendung/-Website hinter Proxy-Servern & Kommunikation mit Azure Service Bus

Eine Anwendung oder Webseite durch einen Proxy von einem Netzwerk nach außen kommunizieren zu lassen ist kein Sonderfall. Der Proxy-Server dient dabei als Kommunikationsschnittstelle und Abgrenzung. Er stellt über seine eigene Adresse eine Verbindung dar.

Allerdings ist es unserer Website oder Anwendung dadurch nicht möglich, direkt nach außen zu kommunizieren. Wenn zum Beispiel global verfügbare Dienste, wie ein Azure Service Bus, angefragt werden müssen, muss die Kommunikation über den Proxy-Server laufen.

Je nach Anwendung bzw. Website gibt es Möglichkeiten, Anfragen über den Proxy laufen zu lassen. Wenn eine importierte Bibliothek (.dll) die Anfragen stellt oder abfängt, müssen gegebenenfalls zusätzliche Einstellungen vorgenommen werden (Siehe Kapitel “Kommunikation durch Assemblies, Beispiel: Azure Service Bus”).

.NET 4 Konsolen-Anwendung

Eine Konsolenanwendung soll Dienste außerhalb des Netzwerks verwenden können. Mit dem Erstellen der Anwendung durch Visual Studio wird die App.config erstellt. Vergleichbar mit web.config von Webseiten, enthält diese Einstellungen für die Lauffähigkeit der Anwendung. Um alle Anfragen der Anwendung nach außen über einen Proxy laufen zu lassen, der beispielsweise mit dem Internet kommunizieren kann, muss folgende Einstellungen in die App.config innerhalb des <configuration> Tags eingefügt werden:

<system.net>
<defaultProxy>
<proxy
proxyaddress=”http://123.45.67.89:8080″
bypassonlocal=”True”
/>
</defaultProxy>
</system.net>

Vollständiges Beispiel App.config:

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<startup>
<supportedRuntime version=”v4.0″ sku=”.NETFramework,Version=v4.6.1″ />
</startup>
<runtime>
<assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>
<dependentAssembly>
<assemblyIdentity name=”Microsoft.IdentityModel.Clients.ActiveDirectory” publicKeyToken=”31bf3856ad364e35″ culture=”neutral” />
<bindingRedirect oldVersion=”0.0.0.0-3.17.2.31801″ newVersion=”3.17.2.31801″ />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name=”Microsoft.IdentityModel.Clients.ActiveDirectory.Platform” publicKeyToken=”31bf3856ad364e35″ culture=”neutral” />
<bindingRedirect oldVersion=”0.0.0.0-3.17.2.31801″ newVersion=”3.17.2.31801″ />
</dependentAssembly>
</assemblyBinding>
</runtime>
<!– Proxy settings for network –>
<system.net>
<defaultProxy>
<proxy
proxyaddress=”http://123.45.67.89:8080″
bypassonlocal=”True”
/>
</defaultProxy>
</system.net>
</configuration>

.NET 4 Website

Um Anfragen von der Website nach außen oder Pakete zur Anwendung über einen Proxy übermitteln zu lassen, muss der gleiche XML-Code in die web.config innerhalb des <configuration>-Tags eingefügt werden:

<system.net>
<defaultProxy>
<proxy
proxyaddress=”http://123.45.67.89:8080″
bypassonlocal=”True”
/>
</defaultProxy>
</system.net>

.Net Core

Da .Net Core über einen eigenen Webserver “Kestrel” verfügt, ist es nicht möglich, über globale Einstellungen alle Requests über einen Proxy laufen zu lassen. Da es zu empfehlen ist, eine Middleware mit Kestrel zu verwenden, kann diese als zusätzlicher Vermittler mit dem Proxy kommunizieren.

Wird Kestrel hinter einen IIS gehostet (ab 2.2 auch im w3wp.exe-Prozess möglich) wird eine web.config vom IIS erstellt, die manuell bearbeitet werden kann. Allerdings ist dies lediglich ein Workaround.

Die empfohlene Variante ist, die Kommunikation selbst zu implementieren. Das “IWebProxy” Interface ist durch “System.Net.Primitives.dll” auch in .Net Core verfügbar.
Siehe: https://docs.microsoft.com/en-us/dotnet/api/system.net.iwebproxy?redirectedfrom=MSDN&view=netframework-4.7.2

Kommunikation durch Assemblies

Beispiel: Azure Service Bus

Eine Anwendung oder Website kann durch eine importierte Bibliothek (Assembly) kommunizieren. Mancher Assembly muss jedoch mitgeteilt werden, dass die oben eingestellten Proxy-Einstellungen ebenfalls für ihre Anfragen gelten sollen.

Als Beispiel muss eine Anwendung sich an einen Azure Service Bus registrieren, um Nachrichten zu erhalten. Durch die Verwendung des SubscriptionClient von “Microsoft.Azure.ServiceBus” muss der TransportType von AMQP (Default) zu AMQP mit WebSockets umgestellt werden, da AMQP ohne WebSocket über TCP und Port 5671 kommuniziert und somit die web.config- oder app.config- Einstellungen keine Auswirkungen haben.
Siehe: https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.servicebus.transporttype?view=azure-dotnet

Der TransportType einer SubscriptionClient kann wie folgt angepasst werden:

ISubscriptionClient subscriptionClient = new SubscriptionClient(<ServiceBusConnectionString>, <TopicName>, <SubscriptionName>);
// Use websocket to use the proxy in web.config for receiving messages
subscriptionClient.ServiceBusConnection.TransportType = TransportType.AmqpWebSockets;

Erfahren Sie mehr

Office 365 Groups als Evolution von SharePoint?
Blog
Blog

Office 365 Groups als Evolution von SharePoint?

Zusätzlich zu SharePoint erlauben die Office 365 Groups es mir als Anwender, schnell und einfach neue Gruppen anzulegen und selbständig Benutzer hinzuzufügen.

Ich bin im Flow! – Eine Übersicht zu Microsoft Flow
Blog
Blog

Ich bin im Flow! – Eine Übersicht zu Microsoft Flow

Die Power Platform wird aktuell von Microsoft sehr stark gepusht. Zeit, sich mit dem Potenzial der einzelnen Komponenten zu beschäftigen. Heute: Flow.

Das neuste Mitglied der Office 365 Familie: Delve
Blog
Blog

Das neuste Mitglied der Office 365 Familie: Delve

Microsoft legt nach: Mit Delve startet eine neue Form des Suchens und des Auffinden von Dokumenten und Informationen.

Azure Functions: Der Webservice ohne Webserver
Blog
Blog

Azure Functions: Der Webservice ohne Webserver

Azure Functions als Authentifizierungs-Helfer für clientseitige Lösungen mit 3rd Party APIs

Paket Dependency Manager für .NET
Blog
Blog

Paket Dependency Manager für .NET

Paket ist ein Dependency Manager für .NET, welcher es sich zum Ziel gesetzt hat einige Probleme von NuGet zu beheben.

Sprechen Sie LUIS? – Der intelligente Chat-Bot im Praxistest
Blog
Blog

Sprechen Sie LUIS? – Der intelligente Chat-Bot im Praxistest

Mit LUIS, der Sprach- und Texterkennungssoftware von Microsoft, und dem Bot Framework von Azure haben wir eine Lösung für den IT-Support entwickelt.

Nov
07
Webcast mit Microsoft: Das Intranet zu Ende gedacht
Webinar
Webinar

Webcast mit Microsoft: Das Intranet zu Ende gedacht

Am 07. November findet erneut eines unserer Webinare gemeinsam mit Mircosoft statt. Das Thema dieses Mal: Das Intranet zu Ende gedacht – Die Informationszentral...

novaCapta auf der Fachtagung für Interne Revision
Event
Event

novaCapta auf der Fachtagung für Interne Revision

Das Expertenteam der novaCapta präsentiert am 15. und 16. November ihre innovative Audit Management Lösung auf dem DIIR-Kongress in Dresden. Besuchen Sie unsere...

May
04
novaCapta auf der dotnet Cologne
Event
Event

novaCapta auf der dotnet Cologne

In nächster Nachbarschaft zu unserem Kölner Büro findet am 04. und 05. Mai die dotnet Cologne im KOMED statt. Wir von der novaCapta sind auch dabei.

PowerApps – Neuigkeiten, Übersicht, Tipps & Tricks
Blog
Blog

PowerApps – Neuigkeiten, Übersicht, Tipps & Tricks

Neues aus der Welt von PowerApps

Valo ist neuer Partner der novaCapta für Intranets
News
News

Valo ist neuer Partner der novaCapta für Intranets

Durch die Partnerschaft mit Valo, dem Ready-2-Go Intranet-Baukasten aus Finnland baut die novaCapta ihr Angebot bei der Umsetzung von schnellen und funktionalen...

Mit der HoloLens ein Stück Berlin nach Köln holen
News
News

Mit der HoloLens ein Stück Berlin nach Köln holen

Im Rahmen eines zweitägigen Hackathons haben sich einige Mitarbeiter der novaCapta der Microsoft HoloLens und dem Thema Mixed Reality gewidmet. Dabei haben wir...