Testnizer v1.4.37

v1.4.37

Client certificates (mTLS) are now actually sent with the request.

• Fixes a client cert that was configured but never presented: a project
  Client Certificate could silently fail to attach, so mTLS servers rejected the
  call (e.g. Visa VDP answered "Expected input credential was not present").
  Two separate causes, both fixed:
  • Host matching. The request matched certificates by the URL's bare
    hostname (sandbox.api.visa.com), but the stored host was whatever you
    typed — commonly a full base URL (https://sandbox.api.visa.com). The strict
    exact-match dropped the cert. Matching is now tolerant of a pasted
    scheme, port, path, and case, and supports * and *.domain patterns.
  • Reading the file at request time. The certificate was stored as a file
    path and re-read on every send. macOS blocks apps from reading
    ~/Downloads, ~/Desktop and ~/Documents, so that read failed and the
    request went out with no certificate. Testnizer now reads the file when you
    pick it (the moment access is granted) and keeps a copy in its own storage —
    the same approach Postman uses — so protected folders are no longer a problem.
• No more silent failure: if a configured client certificate still can't be
  loaded, the request now fails with a clear message telling you why (missing
  file, unreadable folder, wrong file type) instead of quietly sending the
  request without the certificate.

One-time step after updating: open Project Settings → Certificates and
re-select your CRT/KEY (or PFX) files once, so Testnizer copies them into its
own storage.

Tests: the mTLS pipeline is now exercised through the real certificate loader
(the old tests reimplemented it inline and never ran the host filter or the
file-read path — which is why this slipped). New coverage: host matching across
scheme/port/wildcard variants plus a negative case, an unreadable-certificate
error case, and pick-time file capture.