Laden...

Eigene DLL: Fehler in PostAsync, wenn DLL von Gupta genutzt wird: "kein geschützter SSL/TLS-Kanal"

Erstellt von pollito vor 5 Jahren Letzter Beitrag vor 5 Jahren 3.287 Views
pollito Themenstarter:in
314 Beiträge seit 2010
vor 5 Jahren
Eigene DLL: Fehler in PostAsync, wenn DLL von Gupta genutzt wird: "kein geschützter SSL/TLS-Kanal"

Hallo!

Ich brauche wieder eure Hilfe bzw, Denkanstöße.

Ich habe eine DLL entwickelt, mit der ich auf einen Webservice über REST zugreife. Bisher funktionierte sie tadellos, wenn ich sie in andere C#-Projekte einbinde.

Nun soll diese DLL von einem anderen Entwicklungssystem genutzt werden. Hierbei handelt es sich um den sog. "Team Developer" in der Version 6.2 (früher SQL-Windows von der Firma Gupta bzw. Centura). Der Team Developer hat eine Schnittstelle, mit deren Hilfe .NET-DLLs nutzbar gemacht werden können, auch wenn das Entwicklungssystem selbst kein .NET-Produkt ist. Bisher hat das auch funktioniert.

Nun habe ich die DLL eingebunden, allerdings beim Aufruf der unten stehenden Methode wird von der Anweisung

var response = await client.PostAsync(URL, Body);

eine Ausnahme ausgelöst:

Fehlermeldung:
bei System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
bei System.Threading.Tasks.Task1.GetResultCore(Boolean waitCompletionNotification) bei System.Threading.Tasks.Task1.get_Result()
bei isential.paypal.PayPal..ctor(String AuthenticationFile, String Id)
bei isential.Gupta.dotNETWrapper.PayPalGetPaymentInstruction(String AccessDataFile, String TransactionId, String& PaymentInstruction)
System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung. ---> System.Net.WebException: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
bei System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
bei System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResu...

private async Task<Token.RootObject> GetToken(string AuthenticationFile, string URL)
{
	HttpClient client = new HttpClient();

	// Verschlüsselte Datei mit den Anmeldetaten entschlüsseln und einlesen.
	string DecryptedData = Encryption.DecipherFile(AuthenticationFile);

	// Anmeldename und Passwort in jeweils getrennte Feldern speichern.
	string[] DecryptedArray = DecryptedData.Split(new string[] { "\r\n" }, StringSplitOptions.RemoveEmptyEntries);

	// Anmeldedaten für die Abfrage aufbereiten
	string Authentication = Convert.ToBase64String(Encoding.Default.GetBytes($"{DecryptedArray[0]}:{DecryptedArray[1]}"));

	// Standards im Header setzen.
	SetHeaderStandards(client);

	// Authentifizierungsmethode im Header setzen.
	client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", Authentication);
			
	HttpContent Body = new StringContent("grant_type=client_credentials");

	Body.Headers.ContentType = new MediaTypeHeaderValue("application/x-www-form-urlencoded");

	var serializer = new DataContractJsonSerializer(typeof(Token.RootObject));
	var response   = await client.PostAsync(URL, Body); // <<=== AUSNAHME
	var stream	 = await response.Content.ReadAsStreamAsync();

	return serializer.ReadObject(stream) as Token.RootObject;
}

Was ich nicht verstehe, ist die Tatsache, dass unabhängig vom Aufrufer (C# oder Team Developer), alle Werte 100% gleich sind. Von C# aus aufgerufen, funktioniert es, vom Team Developer aus schmiert "PostAsync" ab. Andere mit .NET selbst entwickelte Bibliotheken funktionieren auch ohne Probleme mit dem Team Developer.

Das einzige, was hier gegenüber anderen Bibliotheken etwas anders ist, ist die asynchrone Verarbeitung. Kann es sein, dass dies ein Problem darstellen kann? Ich stehe voll auf dem Schlauch.

Vielleicht fällt jemandem was auf, das mir weiterhelfen könnte.

Im Voraus vielen Dank!

René

3.003 Beiträge seit 2006
vor 5 Jahren

Ich würde eher darauf tippen, dass der Wrapper, der von Gupta benutzt wird, um die .NET-dll aufzurufen, so alt ist, dass er TLS nicht in der Version kennt, die das Gegenüber benutzen möchte. Ich würde meinne Installation von Team Developer 2000 (!) darauf verwetten.

LaTino
(Edit: die schlechte Nachricht - mir fällt nix ein, was man dagegen machen könnte.)
(Edit2: ja. TD 6.2 unterstützt laut http://www.md-consulting.de/wp-content/uploads/2016/10/OpenText_Gupta_Team_Developer_Compatibility_Matrix.pdf nur .NET 4.0 und damit keine neuere TLS-Version. Ihr solltet upgraden.)

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

pollito Themenstarter:in
314 Beiträge seit 2010
vor 5 Jahren

Vielen Dank! Es ist auch nicht mehr selbstverständlich, Leid geplagte Gupta-User anzutreffen, die das Produkt noch kennen X(

Eines verstehe ich aber nicht: Die von uns entwickelte DLL-Bibliothek enthält die gesamte Programmlogik – Gupta instantiiert nur ein Klassenobjekt und ruft eine Methode der C#-DLL auf, welche dann die gesamte Programmlogik steuert. Das passiert aber dann außerhalb der Gupta, so das sie nicht in Berührung mit TLS kommt. Wenn dann die C#-Methode fertig ist, liefert diese das fertige Ergebnis (String-Array) einfach an die Gupta zurück (spezifisch handelt es sich um Zahlungsinformationen für Käufe auf Rechnungen über PayPal-Plus).

Daher verwirrt mich die Aussage mit der TLS-Version, da die gesamte Verarbeitung innerhalb der .NET-DLL stattfindet. Übersehe ich was hier?

Nochmals schönen Dank!

René

3.003 Beiträge seit 2006
vor 5 Jahren

Ja. Deine DLL arbeitet gegen eine .NET-Framework-Version. Wird sie von Gupta gewrappt, arbeitet sie gegen die Frameworkversion, die Gupta eben vorgibt / kennt / unterstützt (ich habe hier selbst nur eine ungefähre Vorstellung davon, wie Gupta arbeitet, weil ich mit pre-.NET-Versionen von Centura arbeite, was noch größere Schmerzen sind). In deinem Fall Framework 4.0. Und die Aushandlung der Transportsicherheit findet durch das Framework statt, nicht durch deinen Code. Dein Code benutzt nur die Infrastruktur, die das Framework bietet. Benutzt du die DLL durch .NET selbst, arbeitest du mit Framework 4.5, die kennt die TLS-Version (ich nehme an, 1.2). Benutzt Gupta die DLL, arbeitest du mit Framework 4.0, und die kennt kein TLS 1.2 und wirft eine Exception.

Zumindest ist das der Reim, den ich mir darauf mache.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

pollito Themenstarter:in
314 Beiträge seit 2010
vor 5 Jahren

Lieben Dank LaTino!

Testhalber habe ich in die DLL folgendes eingebaut:

System.Windows.Forms.MessageBox.Show($"Anwendung kompiliert für: {AppDomain.CurrentDomain.SetupInformation.TargetFrameworkName}");

*Wenn ich die DLL aus der Gupta aus starte, erhalte ich einen leeren String: "Anwendung kompiliert für: " *Wenn ich die DLL aus meiner Testanwendung aus starte, erhalte ich "Anwendung kompiliert für: 4.7.03056 / 461808"

Also es gibt einen Unterschied, den ich aber nicht richtig einordnen kann.

Nun habe ich folgendes versucht: Eine Funktionalität einzubauen, die es nur seit dem C# 7.1 und Framework 4.7 in dieser Art vorhanden ist:

var t = (ID: 1, Name: "René", Entwickler: true);
System.Windows.Forms.MessageBox.Show($"Name: {t.Name}\nEntwickler: {t.Entwickler}\nID: {t.ID}");

Hier verwende ich die vereinfachte Form von Tuples mit benannten Elementen. Das gab es unter 4.0 sicher nicht. Darüber hinaus sind die Stringausgaben mit integrierten Variablen (Dollarzeichen und geschweifte Klammern) auch relativ neu und nicht in 4.0 enthalten. Das alles funktioniert aber anstandslos.

Gut, es mag sein, dass der Compiler daraus kompatiblen Code macht. Ich weiß nun trotzdem nicht mehr, was ich davon halten soll. (Am Liebsten würde ich das gesamte Gupta-Gedöns aus meinem Leben kicken, geht aber leider nicht, da unsere 25 Jahre alte Hauptanwendung einfach zu groß für eine Portierung auf .NET geworden ist.

Wenn ich das Problem nich lösen kann, werde ich eine ausführbare Datei machen müssen, die dann die Gupta aufruft. Hässlich, aber was soll's... Als Gupta-Entwickler ist man Leid gewohnt...

René

16.806 Beiträge seit 2008
vor 5 Jahren

Nun habe ich folgendes versucht: Eine Funktionalität einzubauen, die es nur seit dem C# 7.1 und Framework 4.7 in dieser Art vorhanden ist

Das ist ein Sprachfeature von C# -> Syntaktischer Zucker
Das hat nichts mit .NET, dessen Framework oder dessen Version zutun.

pollito Themenstarter:in
314 Beiträge seit 2010
vor 5 Jahren

Das ist ein Sprachfeature von C# ->
>

Das hat nichts mit .NET, dessen Framework oder dessen Version zutun.

Ja, danke. Das hatte ich bereits stark vermutet:

Gut, es mag sein, dass der Compiler daraus kompatiblen Code macht.

René

78 Beiträge seit 2016
vor 5 Jahren

OT:

Ich glaube der David Tielke (keine Ahnung ob der hier im Forum abhängt) ist ein großer Gupta-Portierungs-Fan. Der kann euch sicherlich helfen.

http://dotnet-paderborn.azurewebsites.net/

pollito Themenstarter:in
314 Beiträge seit 2010
vor 5 Jahren

OT:

Ich glaube der David Tielke (keine Ahnung ob der hier im Forum abhängt) ist ein großer Gupta-Portierungs-Fan. Der kann euch sicherlich helfen. Danke! Noch sind wir nicht soweit, dass wir eine Migration wagen könnten. Technisch müssen wir das System zunächst von altem C/C++-Code befreien – übrig soll nur SAL und C# bleiben. Dann haben wir auch klare Verhältnisse und können uns mit Technik und deren Finanzierung auseinandersetzen, um eine Migration zu planen.

René

pollito Themenstarter:in
314 Beiträge seit 2010
vor 5 Jahren

(...) weil ich mit pre-.NET-Versionen von Centura arbeite, was noch größere Schmerzen sind (...)

OT:
Nochmals vielen dank für die Hilfe. Was Gupta und Entwicklung inkl. Anbindung von DLLs aus der Zeit vor .NET angeht, haben wir viel Know-how angehäuft. Gerne können wir uns austauschen, falls es in diesem Bereich deinerseits Bedarf bzw. Interesse besteht.

Aktuell versuchen wir selbst einen Wrapper für die .NET-Welt zu entwickeln, um die volle Kontrolle über das verwendete Framework zu behalten und nicht auf einem alten Stand sitzend bleiben zu müssen. Wir sehen nach vielen Jahren nicht mehr ein, jedes Jahr viele Tausende von Euro auszugeben, um neue Versionen zu bekommen, die oft nicht das halten was sie versprechen. Das Schließen der Userforen durch OpenText für Nutzer ohne CLS-Vertrag bewog uns schließlich, Gupta den Rücken zu kehren – wir haben alle Verträge gekündigt und sitzen auf der Version 6.2.

Zwei Baustellen haben wir noch:1.Ablösung aller in unverwaltetem Code selbst erstellten DLLs (C/C++) durch neuen SAL- oder besser C#-Code 1.Austausch der Datenbank SQLBase durch MySQL und/oder MS-SQL-Server. Hast du hier Erfahrungswerte?

Nochmals Dankeschön!

René

pollito Themenstarter:in
314 Beiträge seit 2010
vor 5 Jahren

Die Lösung des Problems befindet sich hier:

Es konnte kein geschützter SSL/TLS-Kanal erstellt werden – die 2.

René