.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

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...

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...

Jan
25
Webcast mit Microsoft: Fit für die digitale Arbeitswelt
Webinar
Webinar

Webcast mit Microsoft: Fit für die digitale Arbeitswelt

Die digitale Transformation und die Veränderung der Arbeitswelt ist längst in vielen Unternehmen und in den öffentlichen Einrichtungen angekommen. Dennoch stell...

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.

SharePoint Framework Client-Side Webparts mit React
Blog
Blog

SharePoint Framework Client-Side Webparts mit React

React ist ein Framework zur Erstellen von Benutzeroberflächen. In der SharePoint Online Entwicklung bietet es sich für die Entwicklung von Client-Side Webparts...

Jan
17
Webinar Azure DevOps und Docker Machine
Webinar
Webinar

Webinar Azure DevOps und Docker Machine

DevOps ist in aller Munde, doch was genau verbirgt sich eigentlich hinter dem so viel beschworenen Konzept der IT-Zusammenarbeit? Im Webinar am 17.01.2019 erfah...

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.

Referenz: Miltenyi Biotec

Referenz: Miltenyi Biotec

Der Laborgerätehersteller Miltenyi Biotec entwickelte in Zusammenarbeit mit novaCapta eine auf modernsten Technologien basierende App, die Prozesse der tägliche...

Strukturen lernen und leben – Praxis Informationsarchitektur
Blog
Blog

Strukturen lernen und leben – Praxis Informationsarchitektur

Teil 1 – Strukturen lernen – Informationsarchitektur erfolgreich vertreten

Die Micro-Info-Architektur
Blog
Blog

Die Micro-Info-Architektur

Vertiefung zum Thema Informationsarchitektur moderner Intranets mit SharePoint: Das Micro-Management.

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.

Sliding to heaven – A short story of a SPFx Slider Webpart
Blog
Blog

Sliding to heaven – A short story of a SPFx Slider Webpart

SharePoint Framework, kurz SPFx, ist eine zukunftsträchtige Technologie zur Erstellung von Webparts oder Extensions auf der Basis von TypeScript.