Quantcast
Channel: Chilkat Tech Notes
Viewing all 415 articles
Browse latest View live

Chilkat v9.5.0.88 Pre-Release Notes

$
0
0

The previous version release notes: Chilkat v9.5.0.87 Release Notes

Chilkat v9.5.0.88 Pre-Release Notes

  • PKCS11: Adding the PKCS11 class to bring smart card and USB token functionality to non-Windows systems, and to support smart cards that are problematic when accessed via Microsoft’s CNG and Legacy CSP.
  • 21-June-2021 SFTP:  Added the ability to authenticate with keyboard authentication in the same way as for SSH.   The StartKeyboardAuth and ContinueKeyboardAuth methods are added, and the UserAuthBanner property is added.
  • 8-June-2021 Crypt2: Added the option to calculate “CRC-8” for the CrcBytes and CrcFile methods.
  • 8-June-2021 SSH/SFTP: Added support for the “ecdsa-sha2-nistp521” and “ecdsa-sha2-nistp384” host key algorithms.

Programming Examples for QuickBooks Online API?

$
0
0

Question: I’m am new to QuickBooks having only dealt with desktop version in the past.
Aside Delphi DLL examples about QuickBooks that I guess are only related to the desktop version of the accounting software only, is there any example regarding the QuickBooks online version?

Answer:

I’m looking at the QuickBooks API reference documentation, such as at https://developer.intuit.com/app/developer/qbo/docs/api/accounting/most-commonly-used/account#create-an-account

They provide raw HTTP request samples.
For example, to create an account:

    POST /v3/company//account
    Content type:application/json
    Production Base URL:https://quickbooks.api.intuit.com
    Sandbox Base URL:https://sandbox-quickbooks.api.intuit.com

    {
      "Name": "MyJobs_test",
      "AccountType": "Accounts Receivable"
    }

You can use Chilkat’s online tool at https://tools.chilkat.io/httpRequestToCode.cshtml
to generate code from a raw HTTP request. Just copy/paste the HTTP request into the online tool and generate.

Also:
1) The HTTP start line, which begins with the HTTP verb such as POST, GET, PUT, etc. should NOT have a blank line after it. The 1st header line should immediately follow.
2) There should be 1 blank line between the request header and request body (if the body exists). GET requests will typically not have a body.

Chilkat v9.5.0.89 Pre-Release Notes

$
0
0

The previous version release notes: Chilkat v9.5.0.88 Release Notes

Chilkat v9.5.0.89 Pre-Release Notes

  • Http: Integrated Amazon Pay authentication into the Chilkat HTTP API to eliminate the need for the application developer to directly implement the computations for canonical request and signature.
  • Http: Integrated Duo Security Multi-Factor Authentication (MFA) into the Chilkat HTTP API to eliminate the need for the application developer to directly implement the computations for canonicalization and HMAC-SHA1 signature.
  • Csv: When the Delimiter property is updated, the old delimiter will be replaced with the new delimiter in all rows of the CSV.  The provides the ability to convert a CSV to use a different delimiter, such as converting from comma to semicolon.

Let’s Encrypt “DST Root CA X3 Expiration (September 2021)”

$
0
0

This blog post talks about the Let’s Encrypt “DST Root CA X3 Expiration” that happened today on 30-Sep-2021.

See these articles for a detailed description:   Extending Android Device Compatibility for Let’s Encrypt Certificates
and DST Root CA X3 Expiration (September 2021)

Because the DST Root CA X3 trust anchor cert expired, problems with Chilkat HTTP can occur IF your application set the Http.RequireSslCertVerify = true AND the website uses a Let’s Encrypt cert.   The default value of Http.RequireSslCertVerify is false, so all is OK unless your application explicitly sets Http.RequireSslCertVerify = true.

Many systems explicitly ignore the “notAfter” date for trust anchor certs:

But isn’t DST Root CA X3 expiring? The self-signed certificate which represents the DST Root CA X3 keypair is expiring. But browser and OS root stores don’t contain certificates per se, they contain “trust anchors”, and the standards for verifying certificates allow implementations to choose whether or not to use fields on trust anchors. Android has intentionally chosen not to use the notAfter field of trust anchors. Just as our ISRG Root X1 hasn’t been added to older Android trust stores, DST Root CA X3 hasn’t been removed. So it can issue a cross-sign whose validity extends beyond the expiration of its own self-signed certificate without any issues.

Starting in  v9.5.0.89, Chilkat will ignore the “notAfter” date for trust anchors.  If an application wishes to NOT ignore the “notAfter” date, then it can add the keyword “CheckTrustAnchorExpiration” to the UncommonOptions property.

AKD eID Cards of the Republic of Croatia

$
0
0

Chilkat is going to begin posting about the ongoing work with customers involving smart cards and tokens used for signing PDFs and XML invoices, etc.

Currently, Chilkat is working with a customer to resolve issues having to do with signing PDFs using AKD eID Card for the Republic of Croatia. This is for PKCS11 (AKD eID Middleware PKCS11). The hope is to have this problem solved before the 9.5.0.89 release at the end of Nov 2021.

XML Signature for Guatemala Fel Factura Electronica

$
0
0

(Chilkat is going to begin posting about the ongoing work with customers involving smart cards and tokens used for signing PDFs and XML invoices, etc.)

Chilkat is helping a customer with XML Signatures for Guatemala Fel Factura Electronica, which is to sign XML that begins like the following:

<?xml version="1.0" encoding="utf-8"?>
<dte:GTDocumento xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="0.1" xsi:schemaLocation="http://www.sat.gob.gt/dte/fel/0.2.0 GT_Documento-0.2.1.xsd" xmlns:dte="http://www.sat.gob.gt/dte/fel/0.2.0">
<dte:SAT ClaseDocumento="dte">
<dte:DTE ID="DatosCertificados">

It is believed that the server receiving the signed XML does not like when shorthand XML ends without a SPACE char preceding the “/>”

For example:

This is accepted:  CodigoMoneda=”GTQ” />

This gets rejected:   CodigoMoneda=”GTQ”/>

 

Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using a USB Smart Card

$
0
0

(Chilkat is going to begin posting about the ongoing work with customers involving smart cards and tokens used for signing PDFs and XML invoices, etc.)

The links below are to examples that create a .p7m signature for an Italian e-Invoice (FatturaPA) using a private key stored on a smart card.

It duplicates the following OpenSSL command:

openssl cms -nosmimecap -md sha256 -nodetach -binary -cades -stream \
-outform DER -sign -signer certificato.pem \
-inkey 12345678 -keyform engine -in $1 -out $1.p7m -engine pkcs11

The card used to test is a Bit4id smart card using PKCS11 via bit4xpki.dll

Note: Chilkat has made several fixes and improvements for handling Bit4id smart cards in the last few versions.  If you are using an older version of Chilkat, it’s best to update to the latest version.  In general, improved support for various smart cards and tokens to avoid common problems is an ongoing effort.

C: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Chilkat2-Python: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
C++: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
C#: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
DataFlex: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Delphi ActiveX: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Delphi DLL: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Visual FoxPro: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Go: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Java: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Node.js: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Perl: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
PHP ActiveX: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
PHP Extension: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
PowerBuilder: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
PowerShell: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
PureBasic: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
CkPython: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Ruby: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Tcl: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Unicode C: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Unicode C++: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Visual Basic 6.0: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
VB.NET: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
VBScript: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader
Xojo Plugin: Italian FatturaPA (e-Invoice) Signed XML (CADES-BES P7M) using USB SmartCard Reader

Case-Insensitive JSON

$
0
0

Question: How can JSON be processed in a case-insensitive manner?

Rant followed by Answer:  JSON is intended to be case-sensitive.  XML is the same.  Similar to Java, C, C++, etc.  Names are case-sensitive.   Except, of course, there are knuckleheads out there that don’t understand the fundamental specifications and as a result introduce complexity into systems that should never have existed.  Once a feature is added to allow for case-insensitive names, now you have the situation where some systems work whereas others don’t, and to implement JSON just became more complex.  Microsoft does it:  https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-character-casing     It’s a stupid thing to do.

But… given that the world is prone to stupidity, Chilkat must follow.

The Answer: In v9.5.0.87, Chilkat added the JsonObject property LowerCaseNames:   https://chilkatsoft.com/refdoc/csJsonObjectRef.html#prop14     When the JSON is loaded, the member names are converted to lowercase.  This way you can always use lowercase names and thus the parsing becomes case-insensitive.   (But performance is less impacted because the case conversion only happens once when the JSON is loaded.)

 


.NET RijndaelManaged to Chilkat Equivalent

$
0
0

Here’s a snippet of C# code to do AES encryption.  What is the equivalent in Chilkat?


Dim cspRijndael As New System.Security.Cryptography.RijndaelManaged
csCryptoStream = New CryptoStream(fsOutput, cspRijndael.CreateEncryptor(bytKey, bytIV), CryptoStreamMode.Write)

“Rijndael” is the name of the encryption algorithm, and (essentially) “AES” is Rijndael limited to the choices of 128, 192, or 256 bits.

Rijndael/AES is a symmetric block encryption algorithm, and the size of the IV is always equal to the block size of the algorithm.  The block size for AES is 16-bytes.  This is the block size regardless of key size (whether key is 128-bits, 192-bits, or 256-bits).  Therefore, in the above code, bytIV should always be 16 bytes.   The length of the bytKey byte array determines the key size, and it should be 16 bytes, 24 bytes, or 32 bytes.

The default cipher mode for RijndaelManaged is “CBC”.   (See https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rijndaelmanaged.mode)

The default padding is PKCS7 (See https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rijndaelmanaged.padding )

Therefore, the equivalent code in Chilkat is:
decrypt.CryptAlgorithm = "aes"
decrypt.CipherMode = "cbc"
decrypt.KeyLength = 256
decrypt.PaddingScheme = 0
decrypt.SetEncodedIV ivHex,"hex"
decrypt.SetEncodedKey keyHex,"hex"

Your IV should be 16 bytes encoded as you desire.  The above code snippet specifies “hex”, but could be base64, or other encodings.

The PaddingScheme = 0 is the default, which is PKCS7 padding.  (See the Chilkat online reference documentation for Crypt.)

The KeyLength is in number of bits, and the number of bytes passed to SetEncodedKey should equal the KeyLength/8.

 

 

Support for PureBasic on Apple M1 and Linux arm32/arm64, etc.

$
0
0

Chilkat has received email from customers asking to support PureBasic on M1 Apple silicon and Raspberry Pi.   This is no problem for Chilkat.  We can easily produce the required native .so, .dylib, etc. for each architecture.  We only need documentation from PureBasic about these new architectures.  For example, what are the compiler directives to choose?

We currently have something like this:

  CompilerSelect #PB_Compiler_OS
    CompilerCase #PB_OS_Windows
      CompilerIf #PB_Compiler_Processor = #PB_Processor_x86
        CkJweLibId.i = OpenLibrary(#PB_Any, "chilkatPb32-9_5_0.dll")
      CompilerElse
        CkJweLibId.i = OpenLibrary(#PB_Any, "chilkatPb-9_5_0.dll")
      CompilerEndIf
    CompilerCase #PB_OS_MacOS
        CkJweLibId.i = OpenLibrary(#PB_Any, "libchilkatPb-9_5_0.dylib")
    CompilerCase #PB_OS_Linux
      CompilerIf #PB_Compiler_Processor = #PB_Processor_x86
        CkJweLibId.i = OpenLibrary(#PB_Any, "libchilkatPb32-9_5_0.so")
      CompilerElse
        CkJweLibId.i = OpenLibrary(#PB_Any, "libchilkatPb-9_5_0.so")
      CompilerEndIf
  CompilerEndSelect

 

Validating PDF Signatures with https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation

$
0
0

A Chilkat customer is signing PDFs and then validating using the online tool at https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation

A few errors/warnings were encountered:

1) “The signature is not intact”.   <b>This error only happens if the “ltvOcsp” option was set</b> to create an LTV-enabled signature.  The source of the “Signature is not intact” error can be found here:  https://github.com/esig/dss/blob/master/validation-policy/src/main/java/eu/europa/esig/dss/validation/process/bbb/cv/checks/SignatureIntactCheck.java

When “ltvOcsp” is specified (i.e. we are doing an LTV signature) then Chilkat will send an OCSP request to the OCSP server  for each signing certificate.  The OCSP responses are placed within the pdfRevocationInfoArchival authenticated attribute of the PKCS7 signature.  Also, if countersigning (i.e. signing an already-signed document), then OCSP checks are performed for certs in the existing signature(s), for those certs that have OCSP responders, and only for the cases where an OCSP response is not already in the PDF’s DSS (Document Security Store).   You can see this is complicated shit..

The “signature is not intact” error has to do with the additional parts added with LTV validation.  At this point, we don’t know the specific cause.  It may be that it’s an error specific to the certs used for signing and the OCSP responders involved.

2) “signing time is not present”.  This error happens if the signingTime is not included.  It’s fixed by adding this line:

    json.UpdateInt("signingTime",1);

In addition, the DSS validator will also need the “signingCertificateV2” authenticated attribute:

    json.UpdateInt("signingCertificateV2",1);

 

Chilkat 10-Dec-2021 – Brasilian Tax Server problems?

$
0
0

Chilkat is going to try to blog daily notes on issues we’re handling for customers. So… starting for today..

  • Suddenly SOAP XML posts to the Brasilian tax server https://nfce.sefazrs.rs.gov.br/ws/NfeAutorizacao/NFeAutorizacao4.asmx  stop working with a 415 response code having error “The server cannot service the request because the media type is unsupported.”.    The error “media type is unsupported” generally means the server doesn’t like the Content-Type.  The Chilkat PostXml method uses the “application/xml” Content-Type by default.  Perhaps the server wants “text/xml”.  (An intelligent server would accept either application/xml or text/xml)   The solution might be to explicitly set the Content-Type header to “text/xml” prior to calling PostXml.
  • Problems occur when trying to sign a PDF using a cert issued by e-Mudhra Sub CA for Class 3 Individual 2014.  When Chilkat signs a PDF, the certificate used for signing is validated — meaning the cert’s signature is verified using the public key of the issuer cert, and so on, up to the root CA cert.  Somehow the customer had 2 e-Mudhra Sub CA for Class 3 Individual 2014 certs installed on his system, one with an invalid signature, and one with a valid signature.  Both certs were otherwise identical in all other aspects.  The valid e-Mudhra Sub CA for Class 3 Individual 2014 cert can be downloaded from http://www.e-mudhra.com/Repository/index.html
  • Helping a customer with the Utimaco HSM.  Apparently Utimaco provides PKCS11 support for Windows/Linux (and Mac?), and Microsoft CSP/CNG support on Windows.  We’ve found the CNG route to be non-working.  Cannot get past the simple task of establishing a CNG provider handle by calling NCryptOpenStorageProvider.For Microsoft CNG, we know the CSP name, which is “Utimaco CryptoServer Key Storage Provider”.
    The 1st thing a program must do (i.e. what Chilkat must do) is to get a provider handle by calling NCryptOpenStorageProvider.
    Here’s the Microsoft documentation for that function: https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptopenstorageprovider
    You can see there’s only one input to the function, which is the provider name, and we are passing it correctly. The dwFags argument is always 0
    When we call NCryptOpenStorageProvider, it returns 0x80090011 (NTE_NOT_FOUND)The alternative solution is to use Chilkat’s PKCS11 API to access the certs on the HSM directly. For that, we must know the location and name of the Utimaco PKCS11 driver (.dll, .so, or .dylib depending on the operating system). Chilkat’s PKCS11 API runs on Windows, Linux, and Mac.Also… Utimaco fails when trying to access via SCard. Don’t know what’s up with that!
  • Created a DSA C++ example to help more fully understand the details of DSA signatures:  https://en.wikipedia.org/wiki/Digital_Signature_Algorithm

Chilkat 13-Dec-2021 — PDF Signature not Visible in Chrome or Microsoft Edge

$
0
0

What’s going on with Chilkat support today….

1. Encountered SMTP response of “503: Bad sequence of commands”.   Would need to see the contents of MailMan.LastErrorText for the call to SendEmail, and also the MailMan.SmtpSessionLog.  It’s likely a case where the server does not handle SMTP pipelining, and the MailMan.SmtpPipelining property would need to be set to false.   SMTP pipelining is a way to reduce the number of round-trips (send message, get response) needed to send an email.

2. Investigating claim that in PureBasic,the call to CkDateTime::ckGetAsTimestamp(DateTime, bLocal) crashes with a “Invalid memory access error”, but only on MacOS and MacOS M1.  We suspect a wild goose chase here, but we’ll check it out anyway…    (Yes, it was a wild goose chase.  Everything tested to be fine.)

3. Helping to create/send signed SOAP XML message to TenneT web services (http://sys.svc.tennet.nl/Nominations/sendSchedule)  The best way to solve such a

4. Investigating claim that a PDF signed using this code (in Python) results in a signed PDF where the signature is not visible.  Found out the customer was viewing the signed PDF in Chrome, which for some reason does not show the signature.  However, in Acrobat the signature is visible and appears OK.  Also tested in FireFox: Appears OK.  Tested in Microsoft Edge: The PDF signature does not show.  In summary: Acrobat and Firefox show PDF signatures OK,  Chrome and Edge do not.

5. If a PFX fails to load with the error “Unexpected ASN.1 (3)”, it is because the application atempted to load the binary DER for an X.509 certificate instead of the binary DER for a PKCS12/PFX.  Chilkat was updated to automatically detect the X.509 DER format and load it without error.  Thus, a call to Cert.LoadPfxFile, or CertStore.LoadPfxData, etc. will still work even if a standalone X.509 cert is passed in.

 

Chilkat 14-Dec-2021 — PDF Signature Notes

$
0
0

What’s going on with Chilkat support today…

1. The Http.PostJson, PostJson2, and PostJson3 methods neglect to send a Content-Type header if a completely empty body is sent.  Starting in the next version (v9.5.0.90) Chilkat will always send the Content-Type header for these methods even if the JSON body is completely empty (i.e. a zero-length string where the Content-Length of the body is 0 bytes).

2. PDF Signatures:

  • When signing, the signing certificate and certs in the chain of authentication (to the root CA) are validated (i.e. cert signatures validated against the public key of the issuer, etc.)   If counter-signing, then the certs present in already-existing signatures are also validated unless the “NO_VERIFY_CERT_SIGNATURES” keyword is present in the UncommonOptions property.  The “NO_VERIFY_CERT_SIGNATURES” keyword only applies existing signatures when counter-signing.  It may make sense to avoid verifying the certs in existing signatures because you may not have the required intermediate and root CA certs on your system, thus it may not be possible.  But you should always want to validate the cert used in creating the new signature.  If invalid certs are used, the recipient’s software (such as Acrobat) will certainly notice and report an error.
  • Can Chilkat produce a signature exactly like Adobe Acrobat, using the same graphic?   No.   It would be copyright infringement to use the same graphic/logo, so Chilkat cannot do it.
  • If a JPEG image is included in the visible signature, it must be a JPG saved in the BaseLine format and not Progressive.

3. Question: Is it possible to send email through GMail accounts using “secure authentication” without having to register an application in Google?  The answer is No.  See “Setting Up OAuth 2.0 (Google)” for more information.  You’ll need to create your “app” to get a Client ID / Secret, and then the 1st time a GMail account owner (user of your application) needs to send email, he would need to interactively (via a browser) give permission to your app to access his GMail for the intended purposes (scopes), such as for sending email.  From that point forward, the access token can be refreshed without user interaction.  (OAuth2 access tokens generally expire after some time.)

4. How to handle huge integers in JSON?   Let’s say you have a JSON member such as  { “size”: 2689434955 }.   The Chilkat JsonObject methods for returning a member value as an integer  (such as IntOf and IntAt) return 32-bit signed integers.  If a JSON member is likely to hold an integer exceeding the max size of a 32-bit integer, then you can instead get the value as a string (StringOf, StringAt) and then convert the string to the appropriately typed integer in your programming language.

 

Chilkat 16-Dec-2021 — idToken HTTP Header

$
0
0

What’s going on w/ Chilkat support today…

1. Long HTTP request headers present a difficulty because some web servers choke on header fields that are too long and require folding, whereas others choke on folded headers.  Given that HTTP requests are MIME, and the request/response headers are MIME headers, header folding follows the MIME specification.  Folding SHOULD occur at whitespace.  However, in certain long headers, such as ID tokens or base64 access tokens, there is no whitespace.  Thus Chilkat uses “B” encoding to properly encode.  So you may see a header field like this:

idToken: ?utf-8?B?....=
=?utf-8?B?...=
=?utf-8?B?...=

It was a mistake to fold the idToken and Authorization header fields because the servers that process these header fields choke on the folding.  (Apparently, it’s too much to ask for a server to properly implement the MIME and HTTP specifications — i.e. properly handle MIME header folding.)  In Chilkat v9.5.0.89, we avoid folding the Authorization header.  We now discovered that it’s best to avoid folding the idToken header.

The error returned by the web server that choked on the folded idToken header field was:  status code = 500, Error message “jwt malformed”.

2. Still working to resolve issues with Utimaco HSM.  Apparently it does not support (in PKCS11) the attribute CKA_SUBJECT for private keys.  The Utimaco HSM returns CKR_ATTRIBUTE_TYPE_INVALID when C_GetAttributeValue is called with CKA_SUBJECT.  Damnit.   Anyway.. checking to see if CKA_MODULUS is supported.  We need a way to match the correct private key for a given certificate…

 


Chilkat 17-Dec-2021 — Careful with Network Connections in Garbage Collection Languages

$
0
0

What’s going on with Chilkat support today?

1) Problem report:   My PowerBuilder 10.5 app runs fine, however when I call functions that are using the Chilkat DLL and controls returns to the calling script, the application crashes with the following error:

...
Exception code: 0xc000041d
...
Faulting module path: C:\...\pbdwe105.dll

Solution: Before returning to the calling script, tell Powerbuilder to do a GarbageCollection()

2) When writing code in a programming language that uses garbage collection, such as C#, VB.NET, Java, etc.,  always make sure to close network connections when finished with the object.  This applies to Socket, Imap, Ftp2, SFtp, Ssh, MailMan, Http, Rest, etc.   Connections will be terminated when an object is destructed, but objects aren’t destructed until garbage collection.  Therefore, connections can pile up until suddenly the next connection attempt fails to because the process has too many open connections.

3) Fixed a CSV problem with setting the Delimiter.  In the strange situation where the 1st line of the CSV is garbage (i.e. does not contain cell values), AND if the Delimiter property is set to the default delimiter, which is a comma, then Chilkat will neglect to note that your application explicitly set a delimiter.  Thus.. Chilkat will try to auto-choose the delimiter based on the content of the 1st line, and if that line is garbage, then it can choose wrongly.  This is a rare and strange situation, but it is fixed.

Chilkat v9.5.0.89 Release Notes

$
0
0

The previous version release notes: Chilkat v9.5.0.88 Release Notes

Chilkat v9.5.0.89 Release Notes

  • Http: Integrated Amazon Pay authentication into the Chilkat HTTP API to eliminate the need for the application developer to directly implement the computations for canonical request and signature.
  • Http: Integrated Duo Security Multi-Factor Authentication (MFA) into the Chilkat HTTP API to eliminate the need for the application developer to directly implement the computations for canonicalization and HMAC-SHA1 signature.
  • Csv: When the Delimiter property is updated, the old delimiter will be replaced with the new delimiter in all rows of the CSV.  The provides the ability to convert a CSV to use a different delimiter, such as converting from comma to semicolon.
  • Csv: Added the InsertColumn method.
  • Http: Validating the server certificate chain will now ignore the “notAfter” expire date for trust anchors.  See https://cknotes.com/lets-encrypt-dst-root-ca-x3-expiration-september-2021/
  • Cert: Added the GetExtensionAsText method. 
  • Imap: Fixed a problem with certain mailbox names containing a mixure of “&” and non-us-ascii chars (Chinese chars).
  • Cert.LoadFromSmartcard:  Fixed a problem with loading AKD eID Cards, which are the government official eID cards for the Republic of Croatia.
  • S/MIME: Fixed a problem with decrypting messages that used AES-GCM with a certificate having a non-exportable private key (such that Microsoft CNG is needed internally).
  • TLS: Fixed problems when ECDSA certs are used for 2-way SSL (i.e. TLS client authentication).
  • HttpResponse: Added the methods GetBodyJson, GetBodyJarr, and GetBodyXml.  Also added the UncommonOptions property.
  • Ftp2: Fixed problem with downloading empty files from the Wasabi FTP server.
  • StringBuilder: The GetRange method ignored the last argument which is to tell whether to remove from the StringBuilder the range that is returned.  The range was always removed regardless of the value of the last arg.  This was fixed.
  • SshKey: Now supports the PPK3 file format.

Chilkat 20-Dec-2021 — Does Chilkat support .NET Standard?

$
0
0

What’s going on with Chilkat support today…

1. Does Chilkat support .NET Standard?  We get this question from time to time.  It’s usually because there’s great confusion about the meaning of .NET Standard vs. .NET Core vs. .NET Framework ( and now .NET 5 and .NET 6).   It’s best to first get a solid, basic understanding of the matter.  I recommend reading this:  .NET Standard vs. .NET Core vs. .NET Framework.

Chilkat provides a library for .NET Core via NuGet at https://www.nuget.org/packages/ChilkatDnCore/

Chilkat also provides a library for .NET Framework via NuGet at https://www.nuget.org/packages/chilkat-x64/  and at  https://www.nuget.org/packages/chilkat-win32/

In both cases Chilkat supports all of the .NET Standard versions because it uses very little of the .NET Standard functions.  In other words, both Chilkat implementations (for .NET Core and .NET Framework) are compatible with .NET Standard 1.0, 1.1, 1.2, … , 2.0, …    Chilkat won’t be using new .NET Standard functions in the future, so it will automatically be compatible with future .NET Standard version releases.

Also, at the date of writing this blog post, the Chilkat .NET Core NuGet package supports the following runtimes:  linux-arm, linux-arm64, linux-musl-x64 (Alpine Linux), linux-x64, osx-arm64 (Mac M1), osx-x64, win-x64, win-x86.     Additional runtimes will be added in the future as needs arise.  (i.e. Ask and ye may receive…)

Chilkat 21-Dec-2021 — PHP Versions to Internal PHP API Versions

$
0
0

What’s going on in Chilkat support today…

1. Error: PHP Startup: chilkat_9_5_0: Unable to initialize module

$ php test.php
PHP Warning:  PHP Startup: chilkat_9_5_0: Unable to initialize module
Module compiled with module API=20210902
PHP    compiled with module API=20151012
These options need to match
 in Unknown on line 0
PHP Warning:  dl(): Dynamically loaded extensions aren't enabled in /home/chilkat/chilkat_9_5_0.php on line 22
PHP Fatal error:  Uncaught Error: Call to undefined function new_CkCrypt2() in /home/chilkat/chilkat_9_5_0.php:5943
Stack trace:
#0 /home/chilkat/test.php(5): CkCrypt2->__construct()
#1 {main}
  thrown in /home/chilkat/chilkat_9_5_0.php on line 5943

The above error happens when trying to use Chilkat built for a different PHP version than the version of PHP. The reported module API YYYMMDD numbers indicate the PHP version for Chilkat and the PHP version of PHP itself.

PHP Versions to Internal PHP API Versions

PHP Version API Version
5.2 20060613
5.3 20090626
5.4 20100525
5.5 20121212
5.6 20131226
7.0 20151012
7.1 20160303
7.2 20170718
7.3 20180731
7.4 20190902
8.0 20200930
8.1 20210902

2. Android Socket Permission Denied Error

See https://cknotes.com/android-socket-permission-denied-error/

Chilkat 24-Dec-2021 — CMS Sign Hash

$
0
0

What’s going on in Chilkat support today…

1. A customer needs a way to create a CMS detached signature from a pre-computed hash.  Oddly, Chilkat did not yet have a function for doing it.  The CMS signature functions in Crypt2 accept data and do the hashing internally.  Chilkat is adding a Crypt2.SignHashENC method, as shown here in this example:   https://www.example-code.com/csharp/cms_sign_hash.asp  Obviously, the same example exists in the other programming languages.  Just change the programming language part of the URL.  For example:  https://www.example-code.com/java/cms_sign_hash.asp

2. A prospective customer asked about getting the full name and username from Active Directory (LDAP).  Not Azure AD, but the old AD.   Chilkat does not have this functionality, but one idea might be this:   Find out how it can be done from C#, and then write your own middleware DLL (written in C#) that is called from Delphi.

A) For example, this describes a mechanism to call C# from Delphi:
https://stackoverflow.com/questions/6174584/call-c-sharp-dll-from-delphi

B) And perhaps this has the recipes for doing what is needed in C#:   https://stackoverflow.com/questions/6174584/call-c-sharp-dll-from-delphi

In summary, you might create a C# project that calls the needed functionality in (B) and exports your wrapper functions, which are then called from Delphi.  There may be better solutions, I haven’t looked extensively…

3. An error was encountered on a Windows Server 2012 R2 Datacenter machine when trying to install the Chilkat ActiveX via the .msi (Advanced Installer).  The error was “HRESULT: 0x80070422”.   (Don’t you love the useless HRESULT + hex number error codes?)  Chilkat has never heard of this error previously, so the best course of action is to Google the error.  Type “HRESULT 0x80070422” into Google to find out if others have already solved the problem.  In this case, many of the answers seem to center around “my Windows Modules Installer service was disabled. Go to Control Panel, Administrative Services, Local …”.

Google the error message.

4. Question about how to sign SOAP XML for a tax invoice to be sent to the government of Croatia.  (XML Digital Signature)  This is for XML beginning like this:

<tns:RacunZahtjev xmlns:tns="http://www.apis-it.hr/fin/2012/types/f73" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.apis-it.hr/fin/2012/types/f73.../schema/FiskalizacijaSchema.xsd">
  <tns:Zaglavlje>
    ...

The best way to solve this kind of problem is to take an already signed XML SOAP message that is known to be valid, and then paste it into Chilkat’s online tool at https://tools.chilkat.io/xmlDsigGen.cshtml    The tool will generate the necessary code to produce the signed XML that was input.

Viewing all 415 articles
Browse latest View live