with OverbyteIcsSslHttpRest included, IIS / ISAPI.DLL not responses anymore

[lbucko 0]

Base is a good running ISAPI.DLL for IIS doing bookings for parcels..

 

After adding only two lines in a unit referring on ICS, the DLL doesnt run/respond anymore in IIS ( HTTP Error 503. The service is unavailable.

 

OverbyteIcsSslHttpRest  in uses clause
...(anywhere in a procedure)..

astring := OverbyteIcsSslHttpRest.CopyRight;  // just to compile in the ICS-components.

 

 

Windows-Event Viewer  windows protocols-System states :
AppPool suffered a fatal communication error with the windows process activation service

Source : WAS

EventID : 5011

 

also added webview2loader.dll in IIS to the isapi/cgi-filters as executable allowed - no better result.

 

In a VCL.exe everything runs fine.

After deleting the two lines , the isapi.dll works again.

The Webservice shall use ICS for OAUTH and REST-APIs (in this case for FedEx)

 

Any idea ? order of Units ? Compilerswitches ?

Thank you 🐵

[FPiette 385]

Probably the ISAPI DLL doesn't find the OpenSSL DLLs? Or lack permission to load them.

[Angus Robertson 577]

webview2loader.dll is used to load the Edge browser, no way that will run as a Windows service, no Window.  You can use ICS OAuth2 stuff in services, but only with saved refresh tokens obtained from another application. 

 

If you are using a recent ICS version, the loading problem is probably ICS trying to extract the OpenSSL DLLs from the DLL, never tested that, try disabling define OpenSSL_Resource_Files.

 

The component itself runs fine in a normal DLL, I recently updated OverbyteIcsConHttp.dpr

 

Angus

 

[lbucko 0]

Thank you, for fast response and ideas.

 

The webview2loader.dll was just a test - I do not plan to use it within the webservice.

My idea was, that it may somehow somewhere be preloaded..

It's wired : It's 2 lines in a unit far from the maintasks - I do not touch anything from ICS - just get the Copyright-string within the code - nothing else..

Not even I try to call that unit.

It's only the additional compiled 2xx.000 ICS-lines, which lead "by itself" to a totally not responding of the DLL within IIS.

 

And yes, the trouble only happens in IIS as isapi.dll.

Normal exe and normal DLL: no problem.

 

Ok, I'll follow the idea with the openssl.dlls. After I invest some time with an absolute minimum.dll

But I'm afraid it's something with order of the units, messagepumps, threadmanagement..(webservice is always threaded) - hoped, you had the case already before.

 

I know, I can solve the Auth/REST-webtraffic using Delphi REST Client Framework (already in use in an older unit, same DLL) - but not sure, if Delphi 11.3 REST is already fit for TLS 1.3 and would prefer ICS anyway..

 

I keep you informed here.

 

Lutz

[Angus Robertson 577]

You should also undefine OpenSSL_AutoLoad_CA_Bundle.  This causes OpenSSL to be loaded when any ICS application is loaded, even if no ICS components are used. 

 

This define is usually best since otherwise OpenSSL can be loaded and unloaded repeatedly if not done manually once before making any SSL calls. 

 

I've never tried using ICS in an ISAPI, only simple DLLs, they are not quite standard with a few special exports.  All my Windows 2025 servers run an ISAPI I wrote 20 years ago and last compiled in 2005, never needed to touch it, just keeps working, fortunately Microsoft does not mess with IIS, so nothing ever breaks. 

 

Angus

 

[lbucko 0]

Hi, Angus,

yepp - OpenSSL_AutoLoad_CA_Bundle did the trick - now it runs again - not yet finished with the FedEx-stuff, but at least the service istn't blocked anymore and answers.

 

Solution :

File source\include\OverbyteIcsDefs.inc

 

before:

{$DEFINE OpenSSL_AutoLoad_CA_Bundle}

after:

{.$DEFINE OpenSSL_AutoLoad_CA_Bundle}

 

(deactivated by the point)

 

Thank you, so much !

 

The technic with isapi.dll connected to my .exe-client was for me the best solution, I have found.

no libraries, where I dont know the weak things

no interpreter

superfast

superstable in multithreading

updatable while running

 

The big Carriers like DHL, UPS, FedEx,.. have all their own parcel-APIs/Services - but they have quite a lot interruptions per year and are approx remarkable slower.

And I have also around 12000 bookings per day (in the morning 5000 per hour)

I'm totally satifsied with it - old, but still good and stable.

And with ICS now also prepared for TLS 1.3

 

Ok, I go on realizing the FeDex-Module and give a last Info, if it runs.

The token, I get from oauth will be saved in a lokal variable per thread/object.

Also thank you for that tipp.

 

Lutz

Edited Tuesday at 02:17 PM by lbucko

[Angus Robertson 577]

Be careful with OAuth2 refresh tokens, they do make authentication very simple and usually remain valid for months or even years.  But you must have some code in place for the day the token becomes invalid without notice, immediate emails to the system admin (using the IcsMailQueue component), because otherwise you are going to have hundreds of failed requests very quickly.  Perhaps dummy requests during the night so you get a warning before the rush. 

 

Angus

 

[lbucko 0]

Hi, Angus,

thank you for your tip - I don't plan to work with refreshtoken. I'll ask for one token per transaction.

FedEx states : One hour is the standard Token expiration time.  

 

Ok, I have news
I had to add the DLLs libcrypto-3-x64.dll and libssl-3-x64.dll into the webservicepath
After I had to put them into IIS-isapi/cgi-filter as allowed for executing
In my project I sat
         OverbyteIcsTypes.GSSL_DLL_DIR    := dll_get_basedir; //=dir with the isapi.dll
         OverbyteIcsTypes.GSSL_PUBLIC_DIR := dll_get_basedir;

 

In OverbytetelcsDefs.INC I had to deactivate
{.$DEFINE OpenSSL_Resource_Files}
and
{.$DEFINE OpenSSL_AutoLoad_CA_Bundle}

But still it hang "somewhere".
After experiments and logging I found, that he stops in OverbyteIcsUtils.IcsVerifyTrust at that line :

    Result := WinVerifyTrust (INVALID_HANDLE_VALUE, ActionID, @WinTrustData);

From there he never came back. May be, that this is the exact reason for stucking.

(obviously loading the openssl.dlls and wintrust.dll were succesful - otherwise he would made exit before)

Solution :
For now I solved it dirty (sorry) :

{$IFDEF vlsvc}
    Result := ERROR_SUCCESS;
{$ELSE}
    Result := WinVerifyTrust (INVALID_HANDLE_VALUE, ActionID, @WinTrustData);
{$ENDIF}

..and proudly just got my first token from Fedex with OverbyteIcsSslHttpOAuth.TRestOAuth

Thank you !

Lutz

 

 

[Angus Robertson 577]

Another define to kill, OpenSSL_Check_SignCert will stop the verify trust check, usually that only fails on very old versions of Windows.  

 

OAuth2 uses two tokens, when you authenticate with a login and password a refresh token is generated which usually has a very long expiry, maybe years, and is used to generate an access token which is short lived, an hour to a day, and a new one is generated regularly by ICS from the refresh token.   So you save securely the refresh token, not the access token. 

 

Angus

 

[lbucko 0]

Hi, Angus,

deactivated

{.$DEFINE OpenSSL_Check_Signed} 

solved it also and I deleted my "dirty" solution.

 

Meanwhile the module is running and I can book FedEx.

So you may close this task.

 

Refering on the refresh-token, I found this :

https://stackoverflow.com/questions/55486341/how-to-secure-a-refresh-token

But in this case, I'm not responsible, because my webservice here acts as a client to FedEx and do not create and hold own referesh-token.

 

Thank for your kind support.

 

Lutz

 

btw. : Where can I donate ? And where to send postcard ?