Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 19 16:51
    rlebeau commented #192
  • Sep 19 16:50
    rlebeau commented #192
  • Sep 19 16:50
    rlebeau commented #192
  • Sep 19 16:50
    rlebeau commented #192
  • Sep 19 16:49
    marcin-bury commented #192
  • Sep 19 16:47
    rlebeau commented #192
  • Sep 19 16:46
    rlebeau commented #192
  • Sep 19 15:36
    marcin-bury commented #192
  • Sep 09 16:08

    rlebeau on master

    Allow BIO_set_nbio_accept to be… Merge pull request #429 from ia… (compare)

  • Sep 09 16:08
    rlebeau closed #429
  • Sep 08 00:31
    iadcode commented #429
  • Sep 07 16:25
    rlebeau commented #429
  • Sep 07 08:11
    iadcode commented #429
  • Sep 05 00:52
    iadcode commented #429
  • Sep 05 00:51
    Cirras commented #429
  • Sep 05 00:51
    Cirras commented #429
  • Sep 02 19:59
    rlebeau commented #429
  • Sep 02 00:27
    iadcode commented #429
  • Sep 01 18:25
    rlebeau commented #192
  • Aug 31 17:49
    joostcrommert1 commented #192
marbles99
@marbles99
Thanks.
marbles99
@marbles99
I suspect this might be an SSL issue. I have tried creating a Synapse version of the call and on an older SSL it failed. Using the lastest, it worked. So guess the dilemma looks like not being able to use a later version of SSL that is compatible with the API ciphers in Indy 9. It may be I have to abandon Indy for this project and revert to Synapse if there is not an easy fix, which I suspect it isn't.
Remy Lebeau
@rlebeau
Indy 9 uses customized versions of the OpenSSL DLLs and thus cannot utilize newer OpenSSL versions. You need Indy 10 for that. Indy 9 does support TLS 1.0, though, so I would think turning off 1 cipher would not break as long as the other ciphers are available. If you use a packet sniffer like Wireshark, you can see the cipher list that your app's version of OpenSSL is offering to the server during the handshake.
Another option would be to move your TCP logic to a DLL and update your app to use that, and then write the DLL using Indy 10. Along those same lines, you might consider moving your business logic out of your app to a separate DLL/process so it can be written in a modern Delphi version, and just leave the UI by itself written in D2007.
Walter Prins
@ByteJuggler
@marbles99 Late to this, but, just to ask re "I know ideally, Indy 10 might be the answer but in this instance it is just not possible." Why? (Eric King has successfully installed latest Indy 10 on Delphi 7 recently? Too many dependencies on Indy 9 types or something?)
marbles99
@marbles99

@rlebeau Thanks Remy. I have seen Wireshark mentioned many times on forums and help sites. I will install that and see what kind of data I get back. If I know which cipher fails from that, does that then help? Do I include a list of 'good' ciphers in the cipher list? The library idea seem like a good plan and the way forward. I need to get this working asap in the short term, so need to look at some quick fix options which might mean using Synapse in the the interim (which in tests seems to work, but not as easy as Indy to implement). Once it is working again, I can visit the library idea.

On the subject of Indy 10, I have tried it in Seatlle and get the error I mentioned right at the start. Any idea what that could be? "Ordinal 4430 could not be found...."

marbles99
@marbles99
@ByteJuggler I can't remembet the exact reason why we stuck with Indy 9 for the legacy stuff in D2007. I think it might have been that we have some software that communicates using TCP servers/clients. If my memory serves me correctly, I tried Indy 10 when I reinstalled D2007 on a new PC and it looked like it was going to take some work to convert some of the software to Indy 10. You know what it is like some times, it seemed a quicker option to install Indy 9 so the software would compile. But it is times like this and the problems I have now, that maybe that is false time economy. I probably still don't have the time to go down the Indy 10 on D2007 rout just yet. It would probably mean, for my own peace of mind, cloning my current disk so I have something workable to back to if I need to. Then I need to update and convert all the software. But my priority at the moment is to fix the broken web shop software that is not talking to the API as we are currently unable to automatically update prices and stock. But all these ideas I have taken on board and will return to once I have sorted this other issue. Thanks :)
Walter Prins
@ByteJuggler
@marbles99 Something to do with the particular version of OpenSSL libraries getting pulled in I think. I seem to vaguely recall having had a similar problem in the past and that it boiled down to finding a suitable of SSL libraries. (As I recall not all the Windows libraries are built equal, sorry if this is very vague, it's been a while.) I think (rummaging around my bookmarks) I might've used the build from here eventually: http://slproweb.com/products/Win32OpenSSL.html I would suggest trying a build from there (assuming I'm right and not leading you down the garden path). It should be enough to put libeay32.dll and ssleay32.dll alongside your service/application executable, but to be sure you're not accidentally loading the wrong version you may want to search the machine and rename and/or disable any other versions of these files before testing. (Use "Everything" from voidtools to quickly find all copies of any named file.)
@marbles99 For what it's worth, I seem to remember that, back in the day we were faced with the upgrade from Indy9 to Indy10 it turned out to be slightly less hassle than initially anticipated -- it initially seemed like a lot of work because the breakages seemed bigger than they turned out to be in the end. (Again it's been a while, and obviously YMMV, I have no idea how complicated your dependencies are...)
Walter Prins
@ByteJuggler
@marbles99 (Just to caveat about the SSL lib stuff -- memory's quite vague so I have a feeling I might be mixing this up with something else, perhaps some kind of libsvn thing from the past...)
marbles99
@marbles99
@ByteJuggler Thanks for the quick replies. And for the link to the builds for the SSL libraries. I will take a look at that later today and see if I can see what we need. I am not sure if it will fix the Indy 9 issue as I have used the various versions available from Fulgan which appear to be the 'Indy versions' and there seems to be a point in the library version history where they no longer work with Indy 9 (won't load) but even the latest version there that will load won't connect to out web platform since they removed the cipher. And definitely a good idea to rename all the library DLLs ;) We use them quite extensively for communicating with carrier APIs, Amazon, Web shop platform etc and I wouldn't want to break something that isn't currently broken (except the web platform). I may clone my hard drive this evening and that will give me something easy to go back to. Haven't heard of voidtools, I will take a look. Thanks for your help - appreciated.
Walter Prins
@ByteJuggler
Yes, just to be clear: I'm not suggesting that those builds will work with Indy9 -- Indy9 requires its own special build as it made changes to the libs. Indy10 should work without problems however.
marbles99
@marbles99
Okay, thanks :) Hopefully, at least, it might cure that 'Ordinal not found' issue when I try to connect using SSL in Indy 10 in Seattle.
Walter Prins
@ByteJuggler
Yes... fingers crossed I'm not spouting you know what.
Everything (voidtools): https://www.voidtools.com/ (Can't live without it ;) )
marbles99
@marbles99
Thanks - I will download it now along with Wireshark. Always good to get recommendation for tools that others find useful. Many thanks.
Remy Lebeau
@rlebeau
Indy does not import OpenSSL DLL functions by ordinal, it imports by name, and even then it imports dynamically at run-time, not statically and link-time. My guess is that you are using OpenSSL DLLs that are incompatible with each other, rather than with Indy. In any case, OpenSSL DLLs that are known to work with Indy 10 are available at http://indy.fulgan.com/SSL/ and the DLLs that are compatible with Indy 9 are at http://indy.fulgan.com/SSL/Archive/ (the ones prefixed with "indy_")
marbles99
@marbles99
Hi Remy. That is the really odd thing. I was aware of the Fulgan site and that is the only place I get the SSL libraries from. I had downloaded the latest and that is what I have put into the EXE directory (I redownloaded and recopied again this morning). The version I am using is 1.0.2j. The test program is incredibly simple, just calling an HTTPS to the API using GET. This is using Seattle and Indy 10 with a TIdHTTP and TIdSSLIOHandlerSocketOpenSSL. When I compile and run, it stops at the HTTP GET with the "ordinal 4430 could not be located" error. So I don't know what is happening here. It couldn't be simpler really. A simple GET with HTTPS and hopefully the correct SSL libraries, but something is stopping the SSL loading.
marbles99
@marbles99
This is the line that is throwing the exception (in TIdTCPClientCustom.Connect in IdTCPClient):
blob
These are the SSL options I have set:
blob
marbles99
@marbles99
Actually, going deeper, it's here it fails which I guess is where you would expect if it is going to?
blob
GIdOpenSSLPath is '' and SSL_DLL_name='ssleay32.dll'
Remy Lebeau
@rlebeau
Again, that goes back to my earlier statement that you likely have mismatching DLLs. When ssleay32 is loaded, it has dependencies on other DLLs, and if those can't be loaded than ssleay32 fails to load.
Remy Lebeau
@rlebeau
AFAIK, the latest DLLs work with the latest version of Indy, so make sure you are using DLLs that are packages together
marbles99
@marbles99
Definitely using the same DLLs from the same ZIP, extracted into the EXE directory.
Jeroen Wiert Pluimers
@jpluimers
From a TIdSocketHandle or TIdSocketHandle: is it possible to see who has initiated the connection? i.e. if it's Binding.Peer that initiated to Binding.IP or the other way around?
Remy Lebeau
@rlebeau
@jpluimers A socket is bidirectional, it doesn't know or care which direction the connection was initially established. You will have to keep track of that yourself based on whether the socket is coming from a client component or a server component.
Jeroen Wiert Pluimers
@jpluimers
I was afraid so. No problem: thanks for confirming.
Walter Prins
@ByteJuggler

With apologies in advance for the lengthy post, I'm hoping someone more immediately familiar with the ins and outs of Indy and how its used by Datasnap can point me in the right direction.

I'm trying to make a Datasnap server serve a file with RESUME support. Just making it serve a file is relatively trivial obviously, just add a TDSHttpServiceFileDispatcher component and attach to the TDSHTTPService. However the default service does not appear to support "RESUME" as pausing and resuming a download with (for example) the "DownThemAll" Firefox downloader in fact restarts the download.

In this context, I've found the following post by Remy on SO: http://stackoverflow.com/questions/21494524/indy-http-server-with-resume-support which implies that, at least for Indy, this is the default behaviour and that to support RESUME one has to intercept the GET request and interpose a TIdHTTPRangeStream object if ARequestInfo.Ranges.Count > 0.

Now as Datasnap is based internally on Indy, I'm hoping that I might apply the same approach but it's not entirely clear what the most appropriate place to do so is, as Datasnap abstracts away Indy as an implementation detail in many places and as a result the Indy "Ranges" property is not always available. when you seemingly want/need it.

Based on tracing the Datasnap code my current plan was to patch unit Datasnap.DSHTTP, method TIndyDispatchFileRequest.SetContentStream(AStream: TStream) on line 1555 to essentially do as suggested in the SO post. However the FRRequestInfo object present inside TIndyDispatchFileRequest at that point is not in fact the TIdHTTPRequestObject (that has a Ranges member), and it's not immediately obvious how one might get at it, so I'm wondering whether this is fundamentally perhaps the wrong place/way to tackle this problem.

Question: What is the right approach to tackle this problem? (One other thought I had was to patch IdCustomHTTPServer.DoCommandGet to interrogate the ARequestInfo and AResponseInfo after calling FOnCommandGet...)

(To add: Eventually I'd like to implement a file download using resume support in a Delphi client, as outlined in the following SO question: http://stackoverflow.com/questions/2963246/download-pause-and-resume-an-download-using-indy-components)

Walter Prins
@ByteJuggler
(Using Delphi 10 Seattle)
Remy Lebeau
@rlebeau
@ByteJuggler DataSnap may use Indy internally, but it is not based on Indy. In fact, in recent Delphi versions, Embarcadero has been slowly moving away from Indy in their technologies, like DataSnap, towards their own custom platform-native solutions. That being said, I don't know or use DataSnap, so I could be missing something, but since Indy is being used behind an abstraction layer, I don't see a way to get direct access to Indy's Request/Response objects from DataSnap's wrappers.
Remy Lebeau
@rlebeau
@ByteJuggler looking into it deeper, I just now found that DataSnap's TDSHTTPResponseIndy class has a public ResponseInfo property that is an IPPeerAPI.IIPHTTPResponseInfo interface, which has a public GetObject() method. DataSnap's IPPeerServer.TIdHTTPResponseInfoPeer class implements IIPHTTPResponseInfo, where its GetObject() implementation returns Indy's TIdHTTPResponseInfo object from TIdHTTPServer. But TIdHTTPResponseInfoPeer is a private class in the IPPeerServer unit's implementation section, so you can't access it. But if you manually declare an equivilent class in your own code, you might get away with a type-cast hack to access the Indy object.
Ludwig Behm
@lbehm
I basically intercepted in DoCommandGet and stored the TIdHTTPRequestInfo and TIdHTTPResponseInfo in a __thread local variable, which I can use in my DS ServerMethods
Ludwig Behm
@lbehm
I wrote a replacement for TIdHTTPWebBrokerBridge, removed the WebModule, implemented my own FileDispatcher (based on Indy infrastructure not embarcaderos inet*.bpl) and handle DataSnap related requests to TDSRESTWebDispatcher::DispatchRequest manually
at least serving static files is quite a bit faster now ;)
Jeroen Wiert Pluimers
@jpluimers
Interesting. Is the code public?
Ludwig Behm
@lbehm
@jpluimers If you mean my code, no, not yet
Jeroen Wiert Pluimers
@jpluimers
Let us know if/when.
Mauro Botta
@maurobotta
@rlebeau Hi Remy, Have you any update for TLS 1.2 support of Indy ?

from EMB forum : https://forums.embarcadero.com/thread.jspa?messageID=870089&#870089

Apple will require TLS v 1.2 from 1 Jan 2017, Delphi don't support it ( DataSnap - App ), are there any workaround ?
I need that DataSnap TCP mode ( standalone .exe server ) support TLS 1.2 on Berlin Update 2
Remy thank you for Indy support, Are there any update for it ?

Any link:

https://techcrunch.com/2016/06/14/apple-will-require-https-connections-for-ios-apps-by-the-end-of-2016/
https://plus.google.com/103013776067604117964/posts/b3Si46bjnwA
https://indy.fulgan.com/indy10.changelog.txt

Ludwig Behm
@lbehm
@maurobotta Are we talking about HTTPS? If so, it should be possible.
I don't know about Delphi, but in C++ (Berlin Update1) I simply set ((TIdServerIOHandlerSSLOpenSSL*) Server->IOHandler)->SSLOptions->SSLVersions = TIdSSLVersions(32);
Ohh do you mean direct TCP-Socket-Connections on port 211? I think Apple only cares about HTTPS. So you should be fine
Remy Lebeau
@rlebeau
@maurobotta Indy has supported TLS 1.2 for awhile now. If Embarcadero does not use TLS 1.2 in DataSnap, that is on them.
@devimplode SSLVersions = TIdSSLVersions(32); is not good syntax to use, it is dependant on an implementation detail of how Sets are laid out in memory. You should use SSLVersions = TIdSSLVersions() << sslvTLSv1_2; instead
Ludwig Behm
@lbehm
@rlebeau I tried that... (yes I read the manual =D ) but didn't get it to work. Does my attempt create problems in the memory?
Remy Lebeau
@rlebeau
@devimplode the syntax I showed works fine. Your type-cast will technically work, no problem with memory, but it isn't very readable or well known. I didn't even know Set had a constructor like that until I just now looked at it.
Ludwig Behm
@lbehm
@rlebeau thanks for the infos!^^ The goal was to make it configurable. My result:
_SSLProtocols_ = 0;
TStringList *protoList = new TStringList('"', ':');
protoList->DelimitedText = "tlsv1:tlsv1_1:tlsv1_2";
if (protoList->IndexOf("ssl2") >= 0)
    _SSLProtocols_ = _SSLProtocols_ | 1 /*((int)Idsslopenssl::TIdSSLVersion::sslvSSLv2)*/;
if (protoList->IndexOf("ssl3") >= 0)
    _SSLProtocols_ = _SSLProtocols_ | 2 /*((int)Idsslopenssl::TIdSSLVersion::sslvSSLv3)*/;
if (protoList->IndexOf("tlsv1") >= 0)
    _SSLProtocols_ = _SSLProtocols_ | 8 /*((int)Idsslopenssl::TIdSSLVersion::sslvTLSv1)*/;
if (protoList->IndexOf("tlsv1_1") >= 0)
    _SSLProtocols_ = _SSLProtocols_ | 16 /*((int)Idsslopenssl::TIdSSLVersion::sslvTLSv1_1)*/;
if (protoList->IndexOf("tlsv1_2") >= 0)
    _SSLProtocols_ = _SSLProtocols_ | 32 /*((int)Idsslopenssl::TIdSSLVersion::sslvTLSv1_2)*/;

SSLHandler->SSLOptions->SSLVersions = TIdSSLVersions(_SSLProtocols_);