Hallo,

ich möchte einen String mit Hilfe der Indys in ein Label laden. Im Browser brauche ich dafür weder eine Authentifizierung noch ein Zertifikat, sondern gebe nur "https://www.bitstamp.net/api/ticker/" ein. Deshalb habe ich gedacht, müsste es eigentlich ganz einfach gehen:



Aber da wird über den IOHandler gemeckert.

Ich habe jetzt schon bei den IdHTTP.Optionen hoInProcessAuth und hoKeepOrigProtocol auf true gesetzt, aber das hat nichts gebracht.

Geht das überhaupt mit den normalen Indys oder braucht man für SSL eine spezielle Version?

Ich wäre sehr dankbar, wenn mir jemand sagen könnte, wie ich den Ticker auslesen kann.

Vielen Dank

Moderiert von Martok: Delphi-Tags hinzugefügt

colaka hat folgendes geschrieben :

Aber da wird über den IOHandler gemeckert.

Ob du's glaubst oder nicht: meine Fehlermeldungen sehen immer ganz anders aus.

Achso, bevor ich's vergesse: Pack doch einfach einen IO-Handler dazu

Perlsau hat folgendes geschrieben :

Ob du's glaubst oder nicht: meine Fehlermeldungen sehen immer ganz anders aus.

Das glaub ich Dir aufs Wort.

Zitat:

Achso, bevor ich's vergesse: Pack doch einfach einen IO-Handler dazu

Und wie geht das?

Ich bin leider kein Profi und weiß nicht, was ein I/O-Handler ist.

colaka hat folgendes geschrieben :

Perlsau hat folgendes geschrieben : Ob du's glaubst oder nicht: meine Fehlermeldungen sehen immer ganz anders aus. Das glaub ich Dir aufs Wort.

Was dich aber offensichtlich nicht dazu veranlassen kann, die entsprechende Fehlermeldung auch zu posten, oder? Wieso glauben Anfänger eigentlich immer, daß Profis hellsehen können? Das gehört nämlich definitiv nicht zum Kenntnisumfang des Programmierers, ganz im Gegenteil.

colaka hat folgendes geschrieben :

Perlsau hat folgendes geschrieben : Achso, bevor ich's vergesse: Pack doch einfach einen IO-Handler dazu Und wie geht das? Ich bin leider kein Profi und weiß nicht, was ein I/O-Handler ist.

Du hast doch einen Objektinspektor, nicht wahr? Dort findest du die sogenannten Properties. Wenn du deine TIdHTTP-Komponente auf dem Formular anklickst, sind das die Properties genau dieser Komponente. Unter diesen Properties befindet sich auch eines, das – oh Wunder – IOHandler heißt. Doch, echt, und wenn du's nicht glaubst, dann schau doch einfach mal selber nach.

Nun ist dir sicher auch aufgefallen, daß die URL, die du abrufen möchtest, keine gewöhnliche URL ist, sondern daß dort statt http das "ominöse" https steht. Und was sagt uns dieses zusätzliche s? Genau, daß es sich um eine SSL-Verbindung handelt. Was SSL ist, möchtest du wissen? Da hilft dir Google sicher weiter. Auf jeden Fall müssen wir unserer TIdHTTP-Komponente die SSL-Verschlüsselung irgendwie beibringen. Und genau dafür gibt es in deiner Komponentenpalette nicht nur die Indy Clients, sondern auch die Indy- I/O Handlers. Noch ein Wunder!

Jetzt wirst du sicher fragen, welchen dieser IO-Handler du denn wählen solltest. Wir brauchen was mit SSL. Na, was meinst du?

Nachdem ich einen gewählt und die URL aufgerufen habe, erhalte ich völlig problemlos diesen String zurück:

{"high": "578.38", "last": "562.98", "timestamp": "1393667752", "bid": "561.04", "volume": "25781.81230808", "low": "535.00", "ask": "562.98"}

Vielen Dank,

aber so ganz problemlos geht das bei mir leider nicht.

Ich habe jetzt den IdSSLIOHandlerSocketOpenSSL verwendet. Ich hoffe, das ist der richtige. Beim Ausführen erhalte ich die Fehlermeldung: Could not load SSL library

Offensichtlich fehlen bei mir irgenwelche DLLs.

colaka hat folgendes geschrieben :

Offensichtlich fehlen bei mir irgenwelche DLLs.

Tja offensichtlich. Da kann ich auch nix machen.

Die Open SSL DLLs musst du dir separat herunterladen. Die amerikanischen Gesetze verbieten eine direkte Mitlieferung.

Hallo,

jetzt habe ich die Dateien libeay32.dll und ssleay32.dll eingebunden, doch ich erhalte immer noch die Meldung: "Could not load SSL library".

Über die Handle-Abfrag habe ich überprüft, dass die beiden DLLs geladen wurden.

Was könnte jetzt noch fehlen?

Auf der Indy-Seite gibt es eine ganze Latte von Dateien. Ich habe die neuesten genommen, oder brauche ich für Delphi 2005 bzw. Indy 10.0.20 irgendwelche von den anderen? Welche?

Hallo,

inzwischen habe ich mehr als die Hälfte der auf diesem Server indy.fulgan.com/SSL/ angebotenen Dateien durchprobiert. Bis jetzt hat noch keine Version funktioniert.

Gibt es denn keine bessere Methode, festzustellen, welche Version ich brauche, als alle auszuprobieren?

colaka hat folgendes geschrieben :

jetzt habe ich die Dateien libeay32.dll und ssleay32.dll eingebunden, doch ich erhalte immer noch die Meldung: "Could not load SSL library". Über die Handle-Abfrag habe ich überprüft, dass die beiden DLLs geladen wurden. Was könnte jetzt noch fehlen?

Was verstehst du unter "eingebunden"? Wie hast du das gemacht, dieses "Einbinden"?

colaka hat folgendes geschrieben :

Auf der Indy-Seite gibt es eine ganze Latte von Dateien. Ich habe die neuesten genommen, oder brauche ich für Delphi 2005 bzw. Indy 10.0.20 irgendwelche von den anderen? Welche?

Das weiß ich leider auch nicht.

colaka hat folgendes geschrieben :

inzwischen habe ich mehr als die Hälfte der auf diesem Server indy.fulgan.com/SSL/ angebotenen Dateien durchprobiert. Bis jetzt hat noch keine Version funktioniert. Gibt es denn keine bessere Methode, festzustellen, welche Version ich brauche, als alle auszuprobieren?

Ich verstehe dein Problem nicht so ganz. Du verwendest doch Delphi 2005 pro, also eine gekaufte, lizensierte Professional-Version. Meiner Kenntnis nach sind die Indy-Komponenten da bereits mit drin, so daß sie bei der Installation der IDE automatisch mit installiert werden. Ich kann das aber nicht mit Sicherheit behaupten, da ich nie eine 2005er Version besessen habe.

Falls du Indy nicht nachträglich selbst installiert hast, würde ich daher erst einmal nach den angeblich fehlenden DLLs auf deiner Platte suchen. Solltest du fündig werden, liegt es womöglich an feherhaften Bibliothekspfaden (Optionen).

Hallo,

das Einbinden habe ich so gemacht:



Die Indy-Komponenten sind bei Delphi 2005 pro schon dabei, aber die 2 DLLs nicht. Ich habe sie auch auf meiner Platte bei verschiedenen anderen Programmen, z.B. OpenOffice oder Adobe Bridge gefunden und alle ausprobiert, aber mit keiner Version hat es funktioniert.

Wußt' ich's doch, daß die DLLs bereits in deinem System sind! Wie gesagt, neuere Delphi-Versionen (seit wann, weiß ich nicht) werden mit den Indys ausgeliefert, und zwar mit den vollständigen Indys incl. DLLs.

Offenbar hast du da was grundlegend falsch verstanden: Die beiden DLLs werden von der Indy-Komponente benötigt. Diese Komponente versucht, die DLLs zu laden, findet sie aber nicht. Es hilft dieser IOHandler-Komponente nicht, wenn du die DLLs in irgend einer Unit lädst, wo du sie gar nicht benötigst. Mit anderen Worten: Irgendwo in einer der Units dieser IOHandler-Komponente steht bereits Code zum Einbinden der beiden DLLs, und dort wird auch die Fehlermeldung ausgelöst, daß die DLLs nicht geladen werden konnten. Wie war das nochmal mit dem Nachdenken vor dem Ausprobieren?

Auf einiges von dem, was ich im obigen Post geschrieben habe, bist du leider nicht eingegangen bzw. hast es nicht nachvollzogen: Du mußt in deinen Delphi-Optionen den Bibliothekspfad zu den DLLs eintragen, damit Delphi weiß, wo diese DLLs zu finden sind, falls eine entsprechende Anforderung zum Laden dieser DLLs auftritt.

Welche DLLs wirklich benötigt werden, weiß ich leider auch nicht, denn darum hab ich mich noch nie kümmern müssen. Deshalb kann ich dir auch nicht sagen, ob du die richtigen DLLs heruntergeladen hast. Ich würde jetzt aber trotzdem mal Folgendes machen:

Nimm die neuesten Versionen der heruntergeladenen DLLs und speichere sie in einem Verzeichnis, das bereits als Bibliothekspfad in deinen Delphi-Optionen eingetragen ist, z.B. $(BDS)\lib oder gleich in $(BDS)\Lib\Indy10, das wären dein Lib-Ordner im Delphi-Programmordner bzw. der Unterordner Indy10. Bei mir ist das z.B. C:\Program Files (x86)\CodeGear\RAD Studio\6.0\lib bzw. C:\Program Files (x86)\CodeGear\RAD Studio\6.0\lib\Indy10. Damit sollte dann die Fehlermeldung hinsichtlich fehlender DLLs nicht mehr erscheinen. Sollte das nicht hinhauen, dann stellst du noch einen entsprechenden Suchpfad in den Delphi-Optionen ein.

Perlsau hat folgendes geschrieben :

Falls du Indy nicht nachträglich selbst installiert hast, würde ich daher erst einmal nach den angeblich fehlenden DLLs auf deiner Platte suchen. Solltest du fündig werden, liegt es womöglich an feherhaften Bibliothekspfaden (Optionen).

Wie schon geschrieben...

jaenicke hat folgendes geschrieben :

Die Open SSL DLLs musst du dir separat herunterladen. Die amerikanischen Gesetze verbieten eine direkte Mitlieferung.

Worauf ist denn bei der SSL Komponente SSLOptions.Method eingestellt? Dort kannst du die DLL Version einstellen.

Du könntest einfach die neueste Indy Version nutzen, dann funktionieren auch die aktuellsten DLLs. Ich hätte aber vermutet, dass auch die neueren DLLs abwärtskompatibel sind.
Die DLLs musst du jedenfalls selbst nicht laden, die müssen nur im Anwendungsverzeichnis liegen.

// EDIT:

Perlsau hat folgendes geschrieben :

Du mußt in deinen Delphi-Optionen den Bibliothekspfad zu den DLLs eintragen, damit Delphi weiß, wo diese DLLs zu finden sind, falls eine entsprechende Anforderung zum Laden dieser DLLs auftritt.

Entschuldigung, aber das ist Blödsinn. Der Bibliotheks- oder Suchpfad hat absolut nichts mit dem Verzeichnis zu tun, in dem DLLs gesucht werden. Im Bibliothekspfad sollten die Pfade für Quelltexte, kompilierte Units usw. eingestellt sein, die der Compiler zum Kompilieren nutzen soll.
Im Suchpfad sucht die Delphi-IDE nach den Quelltexten zu kompilierten Units, die der Compiler ggf. nutzt.

Bei mir (Delphi 2009) steht unter SSLOptions.Method "sslvTLSv1". Andere Einstellungen erzeugen Fehlermeldungen. Und in meinem Anwendungsordner liegen keine DLLs. Ich hab keine Ahnung, welche DLLs bei mir für IO-Handler genutzt werden, auf meiner Platte gibt's diese beiden DLLs in vielen verschiedenen Versionen ... Ja und wo stellt man jetzt ein, in welchem Ordner DLLs gesucht werden? Sollte man solche DLLs in Windows\System32 ablegen? Werden DLLs in den Pfaden der Umgebungsvariablen PATH gesucht?

Perlsau hat folgendes geschrieben :

Sollte man solche DLLs in Windows\System32 ablegen?

Besser im Anwendungsverzeichnis, wenn man sie nicht richtig installieren möchte, sprich normalerweise per MSI-Installer. Wenn man sie normal installiert, merkt sich Windows welche Anwendung welche Version einer DLL benötigt und stellt diese auch entsprechend zur Verfügung, wenn sie benötigt wird.

Perlsau hat folgendes geschrieben :

Werden DLLs in den Pfaden der Umgebungsvariablen PATH gesucht?

Unter anderem, ja, aber als erstes in dem Verzeichnis, in dem die Anwendung liegt. Die weiteren Details dazu findest du in der Dokumentation:
msdn.microsoft.com/e...682586(v=vs.85).aspx

Nach langem Bemühen habe ich mich jetzt entschlossen, auf meiner Windows7-Platte, eine aktuelle Indy-Version zu installieren. Offensichtlich gibt es die passenden DLLs für meine Indy-Version nicht mehr. Das funktioniert bis zum Abspeichern. Dabei erscheint die Fehlermeldung:

'C:\ProgramFiles(x86)\Borland\BDS\\3.0\lib\Indy10Neu\System\IndySystem90.dpk' kann nicht zu
'C:\ProgramFiles(x86)\Borland\BDS\\3.0\lib\Indy10Neu\System\history\IndySystem90.dpk.~1~' umbenannt werden.

Die alte Indy10-Installation habe ich vorher deinstalliert, glaube ich jedenfalls. Alle Indy10-Ordner habe ich in Indy10Alt umbenannt und die neuen Indy-Dateien in Indy10Neu kopiert. Die Bibliothekspfade habe ich auch entsprechend angepasst.

Zum Glück habe ich ja noch meine XP-Platte, die ich für Delphi hauptsächlich benutze. Aber bevor ich da auch noch alles vermurkse, möchte ich alles versucht haben, die aktuelle Indy-Version unter W7 zu installieren.

Selbst manuell installierte Komponenten gehören nie ins Delphiverzeichnis, das gilt auch für die Indys, auch wenn die vorher dort lagen. Wir haben für unsere Quelltexte z.B. eine eigene Partition O: und dort ein Verzeichnis O:\Components, in das wir die alle legen, auch z.B. die JEDI Bibliotheken.

Denn im Delphiverzeichnis hast du ja keine Schreibrechte, die aber beim Kompilieren benötigt werden. Deshalb kann das natürlich auch ein anderes Verzeichnis sein, aber es empfiehlt sich ein möglichst kurzes zu nehmen und der Übersicht halber möglichst nicht auf dem Systemlaufwerk, auch wenn das natürlich kein Muss ist.