bcquality/microsoft/knowledge/security/secrettext-with-httpclient.md
Jesper Schulz-Wedde a9f3c50863 Regenerate microsoft/knowledge from upstream BCApps instructions
The previous LLM-generated knowledge files contained factual
hallucinations. The most visible was the claim that `FindFirst` /
`FindLast` "forces a full-table scan" on an unfiltered record - it does
not; those APIs return a single row via the current key.

Other inaccuracies the audit found and fixed:

* `FindSet(true)` was described as "taking a LockTable". The correct
  upstream phrasing is that `FindSet(true)` sets
  `ReadIsolation::UpdLock` on the read. UpdLock and LockTable are
  related but distinct mechanisms.
* The list of production-scale tables had been invented beyond the
  upstream source (e.g. "Detailed Cust. Ledg. Entry") without a
  citation. The regenerated list matches the ten tables upstream lists
  with their P95 row counts.
* `SetLoadFields` guidance had been augmented with an extra mechanism
  claim ("the database resolves the filter using the index without
  hydrating the value") not present in upstream.

Approach: full regeneration of `microsoft/knowledge/` from the six
upstream BCApps Code Review instruction files, with Microsoft Learn /
the AL language reference as a secondary source. Every claim in every
regenerated file is anchored to a verbatim upstream quote (or a Learn
URL); the audit trail lives in artifacts/trace-<domain>.json on the
session workspace.

The PR #11 transaction/error-handling cluster is preserved verbatim:

* performance/understand-implicit-transaction-boundary.md
* performance/codeunit-run-as-atomic-sub-operation.{md,good.al,bad.al}
* performance/codeunit-run-requires-prior-commit-inside-transaction.{md,good.al,bad.al}
* performance/use-tryfunction-for-error-catching-not-rollback.{md,good.al,bad.al}
* performance/avoid-commit-inside-loops.{md,good.al,bad.al}
* security/commitbehavior-attribute-scopes-explicit-commits.{md,good.al,bad.al}
* testing/transactionmodel-attribute-governs-test-transactions.{md,good.al,bad.al}

These articles already cite Microsoft Learn and were carefully
cross-referenced; the regeneration skips their topics rather than
duplicating them.

File counts after regeneration:

  performance   35 .md  (5 preserved + 30 new)
  privacy       17 .md
  security      18 .md  (1 preserved + 17 new)
  style         33 .md
  testing        1 .md  (preserved)
  ui            19 .md
  upgrade       18 .md

Total 141 atomic knowledge files, each strictly one rule. All pass
.github/scripts/validate_frontmatter.py with 0 errors and 0 warnings.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-05-21 09:53:09 +02:00

2 KiB

bc-version domain keywords technologies countries application-area
all
security
secrettext
httpclient
setsecretrequesturi
containssecret
headers
http
al
w1
all

Use the SecretText-aware HttpClient surface for secrets in requests

Description

HttpClient and its companion types expose a parallel surface that accepts SecretText instead of Text, so that secret URIs, secret headers, and secret request bodies never round-trip through plain text. The key entry points are: HttpClient.SetSecretRequestUri() for URIs that contain secrets (the subsequent Get/Post is then called with an empty string); HttpHeaders.Add() overload that accepts a SecretText value for authorization headers; HttpHeaders.ContainsSecret() to test whether a secret header is present (the plain Contains() returns false for secret headers); HttpContent.WriteFrom() and HttpContent.ReadAs() overloads that accept and produce SecretText for request and response bodies that carry credentials.

Best Practice

When the URI contains a secret query parameter, compose it as SecretText (see secretstrsubstno-for-composing-secrets.md), pass it to SetSecretRequestUri, and call Get('', Response) with an empty string as the URI argument. When the credential is an authorization header, build the header value as SecretText and pass it to Headers.Add. Use ContainsSecret rather than Contains to check for the presence of a secret header. See sample: secrettext-with-httpclient.good.al.

Anti Pattern

Calling ApiKey.Unwrap() to build a URI or header string and passing the resulting Text to HttpClient.Get or Headers.Add. The unwrapped secret is now visible in the debugger, in any HTTP trace that captures the request URI, and in any error that includes the URI. Reviewers should flag any Unwrap() call whose result flows into an HttpClient argument; the SecretText overload exists precisely so the unwrap is not needed. See sample: secrettext-with-httpclient.bad.al.