Definitely someone was able to do https in c++ builder 6, can you share it please.
Please share a docs or code sample to do https in c++ builder 6.
The current http request code is working fine but the web service need to disable request via http, will only accept https request later.
Yes, Its a too old 32bit app.
Indy's TIdHTTP definitely supports HTTPS, though you have to tell it which SSL/TLS library you want it to use, by linking an appropriate SSL component to TIdHTTP before connecting to a server.
Which component to use depends on which version of Indy you are using, which you have not stated. I forget whether C++Builder 6 shipped with Indy 8 or 9. But you really should upgrade to the latest Indy 10, which still supports C++Builder 6 (1).
In Indy 8, assign a TIdConnectionInterceptOpenSSL component to the TIdHTTP::Intercept property.
In Indy 9, assign a TIdSSLIOHandlerSocket component to the TIdHTTP::IOHandler property.
In Indy 10, assign a TIdSSLIOHandlerSocketBase-derived component to the TIdHTTP::IOHandler property (2). The default SSL component is TIdSSLIOHandlerSocketOpenSSL (3).
The default SSL components are all wrappers for OpenSSL, so you will also need to deploy the 2 OpenSSL DLLs with your app - ssleay32.dll and libeay32.dll, which you can download from Indy's OpenSSL Binaries repo. Indy 8 and 9 require a customized version of OpenSSL, so they will only work with the indy_openssl096?.zip DLLs in the Archive folder. Indy 10's TIdSSLIOHandlerSocketOpenSSLwill work with official DLLs up to 1.0.2u. For OpenSSL 1.1.x, use this SSLIOHandler component instead (WIP).
(1): support for pre-2009 versions of C++Builder and Delphi will be dropped in Indy 11.
(2): modern Indy 10 can handle this for you.
(3): If you want to use a different TLS library, you will have to wrap it inside of a custom component that is derived from TIdSSLIOHandlerSocketBase and overrides a few virtual methods to delegate read/write operations to the library.
Related
I've to modify a very old app written in Delphi7 and Intraweb to upgrade to the last security requirements (Tls 1.2)
I'm using delphi7, intraweb 8.0.2 (very old, sigh) , indy 10, openssl,
so I started making some simple apps just to test all this components.
If i make a simple server using only Delphi, Indy10, Openssl,
taken from
http://indy.fulgan.com/SSL/openssl-1.0.2c-i386-win32
it works perfectly.
If I atttempt to use Intraweb, specifying port 443 in the ssloptions, as I start the application I get the following error:
exception EidOSSLCouldNotLoadSSLLibray in module Standalone.exe
at 000EE8E1. Could not load SSL Libray
I tried also to intercept the internal error message using the function
WhichFailedToLoad, but it returns an empty string.
So this is the question:
Is it possible to use openssl 1.0.2.c (and also next versions) using
Delphi7, Intraweb 8.0.2 and indy10 ?
It seems to me it's a problem of Intraweb, since the combo Delphi+Indy+Openssl works correctly.
I'd rather not to upgrade to newer versions of intraweb,
but if this is a must we could think to make such an upgrade.
Best regards.
Maurizio
This question already has answers here:
How to statically link Indy SSL files?
(4 answers)
Closed 9 years ago.
How can I build OpenSSL so I can statically link them for use with Indy 10.6 for Windows 32/64 platforms? Is there an in depth guide somewhere to compile without any VC++ dependencies? I heard that Indy needs custom OpenSSL code not the official one. Also what compiler to use? VS2010, VS11, VS13?
It would be nice if it came with .lib files like it does for iOS.
Indy stopped using custom-built OpenSSL DLLs years ago and has been using official DLLs ever since.
However, Indy does not currently support static linking of OpenSSL on non-iOS platforms at this time (there is a TODO item for that, but don't expect it to be implemented anytime soon, unless someone else does it and submits the changes for inclusion in Indy). Even if you could compile static .obj files for OpenSSL on Windows, it would still require some code changes inside of Indy's source to make use of those files. You would have to make those changes manually (see this discussion: How to statically link Indy SSL files) until they are made in Indy natively at some future time.
The only reason Indy supports OpenSSL statically on iOS is because Apple does not allow OpenSSL to be used dynamically on iOS devices (it does in the iOS simulator, though). Every other platform does allow OpenSSL to be loaded dynamically, and that is how OpenSSL is primarily designed to be used.
In Delphi XE2 I'm using Indy 10. I made a small change to one of the units IdHTTPWebBrokerBridge and to take effect, I need to re-build indy. I can't find this in any search, I keep getting results for installing it from scratch - but nothing about re-building what comes with Delphi.
How do I re-build Indy 10?
IdHTTPWebBrokerBridge.pas is included in the Indy release, but it is not actually used by Indy itself. It is used internally by Embarcadero when using Indy inside of DataSnap, and thus is not compiled into Indy itself in any way. So there is no need to recompile Indy itself (unless you want to upgrade it, but be sure to take note of the warnings in the install instructions). You can submit a bug fix to Indy's developers so it is included in future releases, but that will not address your problem in XE2 since DataSnap cannot be recompiled. But if you are using static linking in your project, you could try simply adding the modified IdHTTPWebBrokerBridge.pas file directly into your app.
Okay -- we have an interesting problem.
Some background:
Our main application uses Indy 10. However, we take the Indy 10
source and fix bugs in it, recompile, and install our own set of Indy
components.
We are migrating to Delphi XE and want to start using DataSnap.
DataSnap requires the "official, shipping" version of Indy which is
incompatible with our customized version of Indy.
Our DataSnap servers will be separate applications, but since we
have our own Indy installed in the IDE, we can't "cross the streams".
Okay, therefore, we are unable to use Delphi XE's DataSnap out of the
box because of this compatibility issue.
So my questions is this:
Is it possible to recompile the DataSnap packages in Delphi XE with a new/different version of Indy?
Your thoughts gratefully accepted.
The common belief is No, that's not possible due to not all sources being provided by Embarcadero and some of these sources are reliant on the build of Indy as shipped. (Which is extremely frustrating to end users as the version of Indy that ships with Delphi is out of date relatively quickly and sometimes the version selected at the time is not necessarily a very good one.)
See related SO question:
Is it possible to use Indy 10.5.8.0 in Delphi XE and DataSnap?
Also see the Indy project page:
http://www.indyproject.org/Sockets/Docs/indy10Installation.de.aspx
which states:
Note: In D/CB/RAD 2009+, DataSnap uses
Indy 10 internally. Installing a new
version of Indy will render DataSnap
unusable, as it will not be able to
load the Indy packages anymore.
DataSnap is compiled against the Indy
packages that ship with the IDE, and
DataSnap cannot be recompiled by end
users. If you need to use DataSnap,
then you will need to maintain the
original Indy 10 packages for use in
DataSnap projects.
It's been said that the next version should hopefully allow for easier updates of Indy.
If all DataSnap source is included, is of course possible using some kind of PE executable analisys program to detect which classes and units are used in BPL (as BPLs are just customized DLLs). An very easy one to use is provided with GExperts.
In BPLs, the exports list lines from GExperts\PE Information have an format like #xp$#[nn][UnitName]#[TypeName] (for types) and #[UnitName]{#[Type>]}#[Unit global element like procedures or variables] (for the rest).
You can save that list to a file and GREP to get an list of Units used on a BPL.
Real Examples (vcl140.bpl):
#$xp$11Forms#TForm
#Appevnts#TCustomApplicationEvents#Activate
#Clipbrd#Clipboard
I'm trying to create a SOAP Server application that is a stand alone application (no need for IIS to be configured). The problem is that I get this error when trying to compile:
I get the error
SockApp was compiled with a different version of IdTCPServer
Now this is because Delphi 2006 ships with INDY 10 but SockApp appear to have been compiled with INDY 9.
The read me states:
Include $(BDS)\Lib\Indy9 in the Library path and remove $(BDS)\Lib\Indy10. However, this forces the application to use Indy9.
Compile IndySockTransport and sockapp and put it in $(BDS)\Lib\Indy10.
Option 1 works, but I need to use some of the INDY 10 features so this is not a great option for me.
Does anyone know how to implement option 2? i.e. how do I compile IndySockTransaport and sockapp?
You can also look here: http://www.cromis.net/blog/downloads/cromis-isapi-server/
It is simple to use, flexible (out of the box it works with Indy 9 and 10, but can work with any HTTP components) and tested. It is an ISAPI server side support, but you just build your SOAP module as ISAPI and it works as standalone server. You practically need only few lines of code.
This tutorial covers the steps to build a standalone Soap Server using Indy 9 but it can be modified to work with Indy 10 too:
http://www.digicoast.com/delphi_soap_standalone.html
See also the accepted answer in How to build stand-alone SOAP web services using Delphi? with links to Indy 10 versions