mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 09:26:52 +01:00
Add 15 community knowledge articles from BC Code Intel ingest (#66)
* Add 15 community knowledge articles from BC Code Intel ingest Ingests net-new /community knowledge from BC Code Intelligence, surviving the admission test, gray-zone salvage, and dedup against the full corpus. Domains: ui (6), error-handling (3), performance (2), upgrade (1), appsource (1), security (1), telemetry (1). The two BC24 No. Series migration drafts are merged into one article. Adds good/bad AL samples for the clean-fit articles (error-handling, performance, security, telemetry). UI and appsource remain knowledge-only. Validator and knowledge-index checks pass (207 articles). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Correct SetLoadFields JIT-load article to match MS docs The draft claimed accessing an unlisted field "reloads the entire row" per record. Microsoft's partial-records docs say otherwise: the platform does an implicit Get that loads the missing field(s), and in a direct var loop the first JIT updates the enumerator so later iterations do not re-load. The genuine per-row penalty is the pass-by-value case, where the copy's enumerator is not updated. Rewrite the article around JIT loading and the by-value footgun, rename the slug from ...full-reload to ...jit-load, and fix the good/bad samples to demonstrate the by-value repetition accurately. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Jeremy Vyska <jeremy@sparebrained.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
6281e7e39a
commit
4119417ce4
29 changed files with 613 additions and 0 deletions
21
community/knowledge/security/secrets-isolated-storage.bad.al
Normal file
21
community/knowledge/security/secrets-isolated-storage.bad.al
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
table 50134 "Api Setup Bad Sample"
|
||||
{
|
||||
fields
|
||||
{
|
||||
field(1; "Primary Key"; Code[10]) { }
|
||||
|
||||
// A secret in an ordinary Text field is readable by anyone with table
|
||||
// permission, ships in RapidStart packages and Excel exports, and
|
||||
// appears in record snapshots. No DataClassification tag makes it safe;
|
||||
// it belongs in IsolatedStorage instead.
|
||||
field(10; "API Key"; Text[250])
|
||||
{
|
||||
DataClassification = CustomerContent;
|
||||
}
|
||||
}
|
||||
|
||||
keys
|
||||
{
|
||||
key(PK; "Primary Key") { Clustered = true; }
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
codeunit 50134 "Api Credential Good Sample"
|
||||
{
|
||||
procedure StoreApiKey(ApiKey: SecretText)
|
||||
begin
|
||||
// Credentials live in IsolatedStorage, invisible to record reads, API
|
||||
// pages, RapidStart packages, and Excel export.
|
||||
IsolatedStorage.Set('ExternalApiKey', ApiKey, DataScope::Module);
|
||||
end;
|
||||
|
||||
procedure GetApiKey() ApiKey: SecretText
|
||||
begin
|
||||
if not IsolatedStorage.Get('ExternalApiKey', DataScope::Module, ApiKey) then
|
||||
Error('The external API key has not been configured.');
|
||||
end;
|
||||
}
|
||||
24
community/knowledge/security/secrets-isolated-storage.md
Normal file
24
community/knowledge/security/secrets-isolated-storage.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
bc-version: [all]
|
||||
domain: security
|
||||
keywords: [isolatedstorage, secrets, api-key, oauth-token, connection-string, table-field, credentials]
|
||||
technologies: [al]
|
||||
countries: [w1]
|
||||
application-area: [all]
|
||||
---
|
||||
|
||||
# A secret belongs in IsolatedStorage, never in a table field
|
||||
|
||||
> Contributions welcome — open a PR to refine or extend this article.
|
||||
|
||||
## 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 with `IsolatedStorage`, write it at the point of capture, and read it only when needed. For the per-secret details — choosing the right `DataScope`, encrypting at rest, and typing the value as `SecretText` so it cannot leak into logs — follow `isolatedstorage-datascope-module-vs-company`, `isolatedstorage-setencrypted-for-sensitive-values`, and `secrettext-for-credentials`.
|
||||
|
||||
## 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue