I have a .dll written in C++/Builder of 2007, that uses GSOAP for it's connections to a webservice, It seems to require the location of a .PEM file and it's password (This file is created form a .pfx file delivered by the service organization to authenticate and encrypt). Besides gsoap, it uses openSSL version 0.9.8
Now I need to update SSL to TLS1.2, and this is not covered with openSSL 0.9.8, and updating to version 1.0.2 (the latest I could use) is impossible, because I get a bunch of errors in the OpenSSL code on compilation.
Translation to Delphi 2007 did not really help - since Indy lacks required facilities as well (SOAP1.2 is not supported, it seems) .
However, moving to Ddelphi2018 is on my TODO list so I moved the code for this process to a standalone program (for now) to Delphi. All seems well except for one thing:
in gsoap file stdsoap2.h, there is:
struct SOAP_STD_API soap
…
unsigned short ssl_flags;
const char *keyfile;
const char *password;
…
and the C++ code uses this
struct soap soap;
memset(&soap, 0, sizeof(soap));
...
soap.keyfile = Parms->pCERTIFICAAT; // is .pem bestand, including path
soap.password = "(Certww)"; // hardcoded in deze code....
...
However, In Delphi/Indy I don't see any way to add this data; searc in the internet does give examples of username and password, but seartching on keyfile doesn't show any hits...
What does this do in gsoap, and how to the same in Delphi (2018) / Indy10 ?
Indeed - 10.2 Tokyo..
We found the solution in re-importing the WSDL's into Delphi and use code we already had for accessing certificates.
Related
I work with Firebird and Delphi, I want to implement access via internet with wirecompression;
But I am unable to activate it.
I have followed the steps inside this document for the new parameter(one of the few I was able to find)
How to enable WireCompression on Firebird 3.0 using FireDAC
In the tests I use
Windows server 2012 R2
Firebird : Firebird-3.0.4.33054_0_Win32(32 bits)
Also copied to executable folder.
fbclient.dll
zlib1.dll (idem server and client)
created firebird.conf with wirecompression=true.
and I am giving wirecompression=true inside the Firedac of the application.
Why am I unable to activate the P15:CZ compression ?
Sending connection info for the example:
================================
Connection definition parameters
================================
DriverID=FB
Database=miservidor001:C:\sysdat\C100\gestdat03.fdb
User_Name=SYSDBA
PassWord=*****
WireCompression=true
================================
FireDAC info
================================
Tool = RAD Studio 10.2
FireDAC = 16.0.0 (Build 88974)
Platform = Windows 32 bit
Defines = FireDAC_NOLOCALE_META;FireDAC_MONITOR
================================
Client info
================================
Loading driver FB ...
Brand = Firebird
Client version = 300049900
Client DLL name = C:\APPS\WC01\fbclient.dll
================================
Session info
================================
Current catalog =
Current schema =
Server version = WI-V3.0.4.33054 Firebird 3.0
WI-V3.0.4.33054 Firebird 3.0/tcp (WIN-2012LAGO003)/P15:C
WI-V3.0.4.33054 Firebird 3.0/tcp (nucleo)/P15:C'
NOTE: I don't know Delphi nor FireDAC, this answer is based on the general behavior of Firebird and my experience with maintaining its JDBC driver (Jaybird). So it is possible that there is a better answer specifically for FireDAC/Delphi.
Enabling or disabling wire compression is entirely determined by the client, not by the server. This means that configuration of the server is not necessary nor has it any effect, except in cases where the server itself acts as a client, for example with execute statement ... on external datasource.
To be able to use wire compression, you need three things:
fbclient.dll
zlib1.dll (in the same location as fbclient.dll, or on the search path)
A configuration to enable wire compression for the client
Point 3 is likely your problem: I'm not sure if FireDAC has a connection property WireCompression that actually enables wire compression.
I know of two ways to enable wire compression for the client:
Create a firebird.conf in the same directory as the fbclient.dll used by your application. In this configuration file, put the requested configuration options (one per line):
WireCompression = true
# maybe other config lines (eg AuthClient, WireCrypt, etc)
Instead of creating a firebird.conf file, pass the configuration (with linebreaks separating config options) in the isc_dpb_config (int 87) database parameter item.
The value is the same as the content of the firebird.conf file in the previous option. This may run into size issues if the client is using the old database parameter buffer format (where strings are max 255 bytes) and you want to pass (a lot) more config options.
Option 1 is probably the simplest and will work for all frameworks. Option 2 depends on whether or not the framework or driver exposes the database parameter buffer or if it has a connection property that maps to isc_dpb_config.
For example in Java using Jaybird, you can enable compression (only when using native connections) using:
Properties props = new Properties();
props.setProperty("user", "sysdba");
props.setProperty("password", "masterkey");
props.setProperty("config", "WireCompression=true");
try (var connection = DriverManager.getConnection(
"jdbc:firebirdsql:native:localhost:D:/data/db/fb3/fb3testdatabase.fdb", props)) {
FirebirdConnection fbCon = connection.unwrap(FirebirdConnection.class);
FbDatabase fbDatabase = fbCon.getFbDatabase();
System.out.println(fbDatabase.getServerVersion());
} catch (SQLException e) {
e.printStackTrace();
}
This prints out WI-V3.0.4.33054 Firebird 3.0,WI-V3.0.4.33054 Firebird 3.0/tcp (host)/P15:CZ,WI-V3.0.4.33054 Firebird 3.0/tcp (host)/P15:CZ (note this is <server version>,<server protocol info>,<client protocol info>). The Z in P15:CZ means that the connection is zlib compressed (the C that the connection is encrypted).
Here, the config property is an alias for isc_dpb_config.
Mark's answer is the best (and probably the only) source of information about this problem in the entire internet. Good luck finding anything on Delphi, FireDAC or Firebird documentation about what he said.
Based on his answer, here is what you need to use Firebird wire compression with FireDAC:
You need Delphi Rio 10.3.1 (Update 1) or later. Only in this version the config low level parameter (see below) was added to FireDAC.
You must pass WireCompression=true to the low level config connection parameter. This is NOT TFDConnection.Params (high level).
To accomplish this you need to set the IBAdvanced property of TFDPhysFBConnectionDefParams to config=WireCompression=true (yeah! Go figure it!)
Code:
FDConnection1.DriverName := 'FB';
with FDConnection1.Params as TFDPhysFBConnectionDefParams do
begin
Server := '...';
Database := '...';
UserName := '...';
Password := '...';
IBAdvanced := 'config=WireCompression=true';
end;
FDConnection1.Connected := True;
Using a connection definition file:
[FB_Demo]
DriverID=FB
Server=...
Database=...
User_Name=...
Password=...
IBAdvanced=config=WireCompression=true
You need zlib1.dll in the same path of your fbclient.dll. The catch here is that Firebird distribution DOES NOT have the 32-bit version of zlib1.dll in its C:\Program Files\Firebird\Firebird_3_0\WOW64 folder. So:
If your application is 64-bit you are probably fine. Just use both fbclient.dll and zlib1.dll from your C:\Program Files\Firebird\Firebird_3_0 folder.
If your application is 32-bit you have to download the 32-bit version of zlib1.dll from the 32-bit Firebird distribution. Use it together with the fbclient.dll you find in your C:\Program Files\Firebird\Firebird_3_0\WOW64 (which contains 32-bit libraries).
In Firebird 3.0.4 or later you can use the WIRE_COMPRESSED context variable to check if the connection was established as you expected:
SELECT
RDB$GET_CONTEXT('SYSTEM', 'WIRE_COMPRESSED') wire_compressed
FROM
rdb$database
This will return TRUE if the current connection is compressed.
In a mozille extension I run:
SecSess.Logger.info("ctypes test");
Components.utils.import("resource://gre/modules/ctypes.jsm");
SecSess.Logger.info("1");
this.lib = ctypes.open("libcrypto.so");
SecSess.Logger.info("2");
var a = new Uint8Array(1<<10);
SecSess.Logger.info("3");
var ptr = new ctypes.uint8_t.ptr(a.buffer);
SecSess.Logger.info("4");
Why this ugly logging after each step you might ask? Well this code fails without showing me an error. (or at least I can't find the error message)
This is printed:
ctypes test
1
2
3
So the 5th log message is never printed which means the following statement never completes:
var ptr = new ctypes.uint8_t.ptr(a.buffer);
This is a simplified version of some old code I have to work with and which I also found online as being valid. However it doesn't work. This add-on wasn't developped using the new SDK with jpm. Quite frankly I don't know how and when it was developped but I need to run some tests on it. It comes with a few source files ordered in a components and a modules directory and a chrome.manifest and install.rdf in the root. I copied these files to the extension directory of Mozilla in order for it to work. The extension executes but there seems to be a problem with ctypes. Aren't ctypes fully supported anymore or are these old style add-on no longer valid for the modern Firefox?
Regards,
Roel
I think they landed a a patch to disallow making a pointer from buffers. I'll double check.
Edit:
Ah per this: https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/Using_js-ctypes/Working_with_ArrayBuffers, you don't have to wrap it with a ctypes.uint8_t.ptr just pass it like a.buffer to wherever you need it. :)
My Environment:
C++ Builder XE4
Indy 10.6.0.4975
I am searching information on conversion from host byte order to network byte order.
I found info for Indy 9 using GStack.HostToNetwork(). However, I do not find one for Indy10.
What is corresponding one for Indy10?
You have your information backwards.
There were no TIdStack::HostToNetwork() (or TIdStack::NetworkToHost()) methods in Indy 9. They were TIdStack::WSHToN...() (and TIdStack::WSNToH...()) instead.
TIdStack::HostToNetwork() is for Indy 10. There are also HostToLittleEndian() (and LittleEndianToHost()) functions in IdGlobal.hpp.
I'm testing Synapse and want to know how can I establish a secure connection. I noticed it supports SSL, but I'm not sure whether it suits my needs. I don't have a certificate from CA. I just want to encrypt all data between my server program and client program. Sure, I can encrypt the data myself before sending out. But if SSL can encrypt the data, maybe I can just use it. From what I know, SSL is for "encryption" and "authentication". What I need is only "encryption". Is it possible with Synapse?
UPDATE:
Thanks for helping from daemon_x and the author of Synapse, Lukas Gebauer, I think I finally make it work. Here are what I did:
Server Side:
1) Uses ssl_openssl in your unit and put 'libeay32.dll' and 'ssleay32.dll' to the same directory of the exe file
2) After a connection is accepted, add following lines of code for the newly created socket.
fclient.SSLAcceptConnection;
Client side:
1) Uses ssl_openssl in your unit and put 'libeay32.dll' and 'ssleay32.dll' to the same directory of the exe file
2) After connected to the server, add following line.
fclient.SSLDoConnect;
If no error occurred, the connection is secure now. But when you run your code, as said in document of Synapse, you may notice that the SSLAcceptConnection takes some time to return. So if you want to speed things up, you better create a certificate file and private key file upfront. And add following code before SSLAcceptConnection
fclient.SSL.CertificateFile := 'bs-cert';
fclient.SSL.PrivateKeyFile := 'bs-privatekey';
If you don't have a certificate and private key, please refer to "CreateSelfSignedCert" in ssl_openssl for getting a self-signed certificate and private key. You can save, by WriteStrToStream for example, FCertificate and FPrivatekey to files and use them later.
Yes it is; you can use one of the plugins shipped with Synapse. As it's also mentioned there, the best is to use the ssl_openssl.pas. If you decide to follow this one you will need except Sysapse also the OpenSSL library. Author recommends OpenSSL 0.9.7 but as he said on our local forum it seems to works also with OpenSSL 1.0.0d.
Note if you are using D2009 up you will need a Unicode support which is not fully supported in version. Download the latest version instead.
The following sample code receives first 1024 bytes as a response to the HTTP GET method of a secured website using SSL encryption. I've used for it OpenSSL 0.9.8h with the latest version of Synapse. Note you need to put libssl32.dll and libeay32.dll from the OpenSSL package into your output directory to make it work properly. Let's have a form with a button and memo where we receive a result.
uses blcksock, synautil, synsock, ssl_openssl, ssl_openssl_lib;
procedure TForm1.Button1Click(Sender: TObject);
var Socket: TTCPBlockSocket;
begin
Socket := TTCPBlockSocket.Create;
try
Socket.Connect('www.yousendit.com', '443'); // connect to the host
Socket.SSLDoConnect; // start SSL connection; only server has a certificate
if Socket.LastError = 0 then
begin
Socket.SendString('GET' + CRLF); // request GET method
Memo1.Text := Socket.RecvBufferStr(1024, 1000); // receive 1024 bytes
end;
finally
Socket.Free;
end;
end;
I have the following declaration for DNSServiceRegister:
function DNSServiceRegister
(
var sdRef: TDNSServiceRef;
const flags: TDNSServiceFlags;
const interfaceIndex: uint32_t;
const name: PUTF8String; //* may be NULL */
const regType: PUTF8String;
const domain: PUTF8String; //* may be NULL */
const host: PUTF8String; //* may be NULL */
const port: uint16_t;
const txtLen: uint16_t;
const txtRecord: Pointer; //* may be NULL */
const callBack: TDNSServiceRegisterReply; //* may be NULL */
const context: Pointer //* may be NULL */
): TDNSServiceErrorType; stdcall; external DNSSD_DLL;
In my Bonjour framework I have the following response to an announced service being made active (i.e. to actually start announcing itself, via Bonjour):
procedure TAnnouncedService.Activate;
var
flags: Cardinal;
name: UTF8String;
svc: UTF8String;
pn: PUTF8String;
ps: PUTF8String;
begin
fPreAnnouncedServiceName := ServiceName;
inherited;
if AutoRename then
flags := 0
else
flags := kDNSServiceFlagsNoAutoRename; { - do not auto-rename }
if (ServiceName <> '') then
begin
name := ServiceName;
pn := PUTF8String(name);
end
else
pn := NIL;
svc := ServiceType;
ps := PUTF8String(svc);
CheckAPIResult(DNSServiceRegister(fHandle,
flags,
0 { interfaceID - register on all interfaces },
pn,
ps,
NIL { domain - register in all available },
NIL { hostname - use default },
ReverseBytes(Port),
0 { txtLen },
NIL { txtRecord },
DNSServiceRegisterReply,
self));
TBonjourEventHandler.Create(fHandle);
end;
This is more verbose than I think it strictly needs to be, certainly it was working perfectly well in Delphi 7 in a much less verbose form. I have expanded a lot of operations into explicit steps to facilitate debugging, e.g. to be able to identify any implicit transforms of string payloads that may be occuring "under the hood" in Delphi 2009.
Even in this untidy expanded form this code compiles and works perfectly well in Delphi 7, but if I compile and run with Delphi 2009 I get no announcement of my service.
For example, if I run this code as part of a Delphi 7 application to register a _daap._tcp service (an iTunes shared library) I see it pop-up in a running instance of iTunes. If I recompile the exact same application without modification in Delphi 2009 and run it, I do not see my service appearing in iTunes.
I get the same behaviour when monitoring with the dns-sd command line utility. That is, service code compiled with Delphi 7 behaves as I expect, compiled in Delphi 2009 - nothing.
I am not getting any errors from the Bonjour API - the DNSServiceRegisterReply callback is being called with an ErrorCode of 0 (zero), i.e. success, and if I supply a NIL name parameter with AutoRename specified in the flags then my service is allocated the correct default name. But still the service does not show up in iTunes.
I am at a loss as to what is going on.
As you might be able to tell from the expansion of the code, I have been chasing potential errors being introduced by the Unicode implementation in Delphi 2009, but this seems to be leading me nowhere.
The code was originally developed against version 1.0.3 of the Bonjour API/SDK. I've since updated to 1.0.6 in case that was somehow involved, without any success. afaict 1.0.6 merely added a new function for obtaining "properties", which currently supports only a "DaemonVersion" property for obtaining the Bonjour version - this is working perfectly.
NOTE: I'm aware that the code as it stands is not technically UTF8-safe in Delphi 7 - I have eliminated explicit conversions as far as possible so as to keep things as simple as possible for the automatic conversions that Delphi 2009 applies. My aim now is to get this working in Delphi 2009 then work backward from that solution to hopefully find a compatible approach for earlier versions of Delphi.
NOTE ALSO: I originally also had problems with browsing for advertised services, i.e. identifying an actual iTunes shared library on the network. Those issues were caused by the Unicode handling in Delphi 2009 and have been resolved. My Delphi 2009 code is just as capable of identifying an actual iTunes shared library and querying it's TXT records. It's only this service registration that isn't working.
I must be missing something stupid and obvious.
Does anyone have any ideas?!
UPDATE
Having returned to this problem I have now discovered the following:
If I have a pre-D2009 and a D2009+ IDE open (e.g D2006 and D2010) with the same project loaded into both IDE's concurrently:
Build and run under 2006: It works - my service announcement is picked up by iTunes
Switch to D2010 and run (without building): It does a minimal compile, runs and works.
Do a full build in D2010: It stops working
Switch back to D2006 and run (without building): It doesn't work
Do a full build in D2006: It works again
Does this give anyone any other ideas?
The answer to this is mind boggling. On the one hand I made a completely stupid, very simple mistake, but on the other hand it should never - as far as I can see - have worked in ANY version of Delphi!
The problem was nothing what-so-ever to do with the Unicode/non-unicodeness of any strings, but was actually due to a type mismatch in the PORT parameter.
I was passing in the result of ReverseBytes(Port) - that parameter expected a uint16_t, i.e. a Word value. My Port property was however declared (lazily) as an Integer!!
Once I fixed this and had Port declared as a Word, it now works on both D2007- and D2009+ versions of Delphi.
Very weird.
I can only think that some other edge-case behaviour of the compiler that might have somehow affected this was changed when Unicode support was introduced.
Based on the information that we have available here, the situation is this:
When calling the DLL with your code in Delphi 2007, it gives one result.
When calling the same DLL with your code in Delphi 2009, it gives another result.
The suspicion is, that it is related to the Delphi 2009 compiler.
Logically, the difference must therefore be, that Delphi 2009 sends different values as parameters. In order to make the debugging truly Delphi-independent, you therefore need to create a dummy DLL, which reports the values it gets. Other Delphi-dependent methods may be applied, like looking at the disassembly of the function-call into the DLL, and debugging it so that we know exactly what values are passed, and how, to the DLL, in both compilers.
I can't find the declaration instruction for the vars "ServiceName" and "ServiceType" in your code sample.
Assuming a String type (thus a unicode string), I guess (yes... no D2009 available to test this) lazy typecasting could be an issue:
name := ServiceName;
Why not use the following?
name := PAnsiChar(AnsiString(ServiceName))
Anyhow... just my 2 cts.
BTW:
I always use the pre defined "EmptyStr", "EmptyWideStr" ... so the test would look like:
if (ServiceName <> EmptyStr) then
which should be safe and avoid the confusion of types.
On the other side, Delphi may interpret the '' as an ANSIChar like the following declaration do:
const
MyParagraphChar = '§';
Not sure... I'm confused - should go home now ;)
If the DLL is not written using Delphi 2009, you may want to use something else than PUTF8String. The Delphi 2009 Utf8String type is different from Delphi 2007's UTF8String type.
If the DLL was written using C/C++, I strongly suggest to use PAnsiChar() instead of PUtf8String.