186d8a1314
* Complete AL review knowledge readiness Fill telemetry and Query coverage, strengthen thin review domains, correct audited content defects, and add deterministic cheap-model evaluation and reference-integrity safeguards. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27 * Generalize review fixture discovery Derive smoke cases from the leaf, domain, and paired-sample conventions so new leaves require no scoring-contract changes. Keep only exceptional selection/context overrides and fail when retrieval metadata cannot rank the selected article. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27 * Preserve published field IDs in sample Keep the existing Email and Contact Email field IDs unchanged, clarify that the sample represents an independent baseline, and use a local breaking-change rule for the generic smoke evaluation. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27 * Clarify published field identity rules State explicitly that a published field keeps its ID, name, and type while a replacement is added as a separate field under an unused ID. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27 * Align field obsoletion sample baselines Use Email field ID 3 as the shared baseline so the bad example demonstrates a same-ID rename while the good example retains the original field and adds a separate replacement. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27 --------- Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>
2 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
security |
|
|
|
|
A secret belongs in IsolatedStorage, never in a table field
Description
API keys, OAuth tokens, client secrets, and connection strings must not be stored in an ordinary table Text field — not even on a hidden setup table. A regular field is exposed through record reads, page display, RapidStart and Excel export, report datasets, and surfaces in DataClassification review; anyone with table permission can read it. The correct home is IsolatedStorage, which is invisible to database queries, API pages, and configuration packages. The storage-location decision is the rule here; how to scope and encrypt the value once it is in IsolatedStorage is covered separately.
Best Practice
Persist every credential in IsolatedStorage, write it at the point of capture, and read it only when needed. Prefer SetEncrypted when the value fits its documented length limit. On BC24 and later, carry the value through the SecretText overloads; on earlier releases, keep any required Text handling inside a [NonDebuggable] boundary. Choose the DataScope that matches the credential's lifetime. See isolatedstorage-datascope-module-vs-company, isolatedstorage-setencrypted-for-sensitive-values, and secrettext-for-credentials for those separate concerns.
See sample: secrets-isolated-storage.good.al.
Anti Pattern
A "Setup" or "Connection" table carrying a Text field named API Key, Password, or Client Secret. The value is now readable by any object with table permission, ships in RapidStart packages and Excel exports, and appears in record snapshots — a credential disclosure that no amount of encryption-in-transit elsewhere makes up for. Reviewer signal: a secret-shaped field declared on a table instead of an IsolatedStorage call.
See sample: secrets-isolated-storage.bad.al.