Relaesewechsel im GAD-Rechenzentrum - Ursache HTTP-Fehler ??

>> Es geht hier um Banken die der GAD angeschlossen sind und daher teste ich auch nur diesen Zugriff.

Und ich stelle mir die Frage warum es mit anderen Banken/RZ funktioniert, nur mit GAD-RZ nicht.
Da nützen auch die ganzen Malware-Verschwörungs-Theorien nichts, weil
a) www.kontex.de nicht in dem Vorgang einbezogen ist.
b) nur ein reiner HTTP-Datenstrom fließt

>> Ich habe Kontex inkl. FiBu installiert (HKVVB:4:3+0+0+0+www.kontex.de 2013.0525.0+PR669).
>> Kann ja entsprechend von http://www.kontex-server.de/download/ geladen werden.

Clever

>> Erst kommt der 503-Fehler, dann geht es auf einmal und dann geht es wieder nicht.

Siehste, es funktioniert also gelegentlich mal.
Und warum nicht immer

>> Im gesamten Zeitraum war die Datenübertragung mit einer GAD-Bank und einem anderen Zahlungsverkehrsprogramm möglich
>> und die Adresse https:// hbci-pintan.gad.de/cgi-bin/hbciservlet konnte jederzeit im Browser aufgerufen werden.

Und was ist da anders.
Den Datenstrom kannste ja nu vergleichen.

Warum soll ich deinen Job machen, siehe Hinweise von obnutzer zum Debugging/Logging.

Wenn es auf einem Rechner mit Kontex nicht funktioniert und mit einer anderen Software auf dem gleichen Rechner 1 Sekunde später keine Probleme auftreten, dann liegt es meiner Meinung nach an Komex.

Auch sporadische Problem können durch Kontex verursacht werden, stattdessen wird dies auf das Rechenzentrum geschoben, obwohl andere Produkte keine 503-Probleme haben. Der Verweis auf andere funktionierende Rechenzentren interessiert dabei nicht.

... ist nur die Frage, ob man mit dieser Einstellung weiter kommt und sich und seinen Kunden weiterhilft.

Einfach mal eine andere ZV-Software auf dem Kundenrechner installieren und prüfen, ob es auch zum 503-Fehler kommt, sollte nicht schwierig sein.

Allerdings besteht die Gefahr dass damit keine Probleme auftreten und deine Kunden deine Software in Frage stellen werden.

Viel Erfolg dabei!!!!

Worüber ich mir immer noch nicht im klaren bin, ob du echt über das Problem mit mir diskutierst oder aber (versteckte)-Lobby-Arbeit für GAD leistest.
Das war mein erster Gedanke auf dein Posting "... sollte man sich zurückhalten".
Sorry für meine Ehrlichkeit und Danke für die bisherige Diskussion.
Woher soll ich denn wissen ob andere Produkte auch Probleme haben. Meist wird das doch totgeschwiegen.
Mit Fehlern anderer und deren Unvermögen diese zuzugeben haben wir zu oft zu tun, das kannste mir glauben. (am 14.05. mit Fiducia erst erlebt wg. "Berechtigungs-Problem" siehe HNA)

Gute Nacht - jetzt aber wirklich

Dann wirst du einen Fehler - so er denn auf eurer Seite liegt - nicht finden. Ziehe am besten einen Netzwerkadmin mit hinzu, der soll das mal sniffen.


Die Zertifikatsprüfung siehst du nicht auf Anwendungsebene. Die sollte die Software bzw. die von ihr verwendeten Kommunikationskomponenten auf einer tieferen Ebene machen. Und die sollte sie IMMER machen, damit sichergestellt ist, dass man mit der richtigen Gegenstelle "spricht", denn dafür ist ein Zertifikat da. Hat mit tanpflichtigen Vorgängen nichts zu tun.
Und jetzt sag mir nicht, dass eure Programme eine https Verbindung im Bankumfeld ohne Zertifikatsprüfung aufbauen. Falls es wirklich so sein sollte, schreib es im Sinne von Kontex bitte nicht öffentlich. Das könnte geschäftsschädigend sein.

Mal generell die Empfehlung des Studiums dieser Seite: https://de.wikipedia.org/wiki/…col_Secure
Und die zieht hier auch dann, wenn ihr keinen Browser sondern eine andere Software verwendet. Die zugrundeliegenden Systematiken sind die selben.


Und wieso warnt Google nun "zufällig" zeitgleich auch vor der Seite? Ich glaube in der IT nicht an Zufälle, sagte ich das schon mal?

Konkret kann ich die den Grund natürlich nicht nennen aber meine Vorstellungskraft ist unendlich. Ihr müsst das tiefer debuggen, schon allein um der GAD - soweit sie denn überhaupt einen Anteil an der Auswirkung hat - den Nachweis zu liefern.
Bis jetzt wurden zumindest in meinen Augen noch keine Fakten geliefert, die eindeutig für oder gegen eine einseitige Schuld eines Beteiligten sprechen. Sowohl das wechselhafte Funktionieren und Nichtfunktionieren als auch der 503er können durch Fehler auf beiden Seiten zustande kommen.
Und da anscheinend im Moment nur Kontex das Problem hat muss Kontex aktiv werden. Und das heißt nicht, die Schuld auf GAD zu schieben sondern tiefer zu forschen.
Übrigens habe ich mit der GAD soviel zu tun wie der Papst mit der Schinkenstraße.

Eine Frage fällt mir noch ein: Agiert dieses Kontex wie ein Rechenzentrum und holt die Umsätze mit EINER Benutzerkennung und PIN für alle Kunden ab? Oder gibt jeder Teilnehmer seine eigene Kennung+PIN ein?

Zum Beispiel mit der DDBAC

Ja, ich glaub das ist es. Das würde die Google Reaktion erklären und auch die Großflächigkeit. Die haben ein IP-Problem.
Das ist bisher zumindest die beste Theorie in meinen Augen.

Bei einem IP-Problem müsste ich auch das Problem mit anderen Programmen haben. Ich habe heute vormittag erfolgreich mit Kontext die Umsätze abrufen können. Jetzt kommt wieder der 503-Fehler.

Ich vermute, dass das Problem dadurch verursacht wird, dass die Daten zuerst an 81.169.133.202 gesendet werden und nicht direkt mit https:// hbci-pintan.gad.de/cgi-bin/hbciservlet kommuniziert wird.

Bei einer direkten Kommunikation mit https:// hbci-pintan.gad.de/cgi-bin/hbciservlet auf dem gleichen Rechner treten keine Probleme auf.

Nein, natürlich nicht bei denen. Oh Mann, tust du nur so?
Wieso sollte ich schreiben, dass das auch die Google Reaktion erklärt?
GAD und Fiducia haben mit Google doch kein Problem.

Das IP-Problem liegt natürlich auf Clientseite, also irgendwo in der Kontex Sphäre!
Warum rate ich denn die ganze Zeit, dass der Admin mal das Netz snifft?