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>
1.4 KiB
| bc-version | domain | keywords | technologies | countries | application-area | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
security |
|
|
|
|
Set secret request URIs on HttpRequestMessage
Description
The secret URI API belongs to HttpRequestMessage, not HttpClient. HttpRequestMessage.SetSecretRequestUri(SecretText) keeps a credential-bearing URI protected, and the prepared request is sent with HttpClient.Send. Companion APIs also accept SecretText, including HttpHeaders.Add for authorization headers and HttpContent.WriteFrom for secret request bodies.
Best Practice
Compose a secret URI with SecretStrSubstNo, call Request.SetSecretRequestUri(SecretUri), set the request method, and send the request with HttpClient.Send(Request, Response). For authorization, get the request headers, add a SecretText value, and use ContainsSecret when checking for that header. See sample: secrettext-with-httpclient.good.al.
Anti Pattern
Holding a credential in Text, interpolating it with StrSubstNo or concatenation, and passing that plain text to HttpClient.Get or HttpHeaders.Add. The secret-aware request and header APIs remove the need to materialize the value as Text. This HTTP-sink rule supersedes the generic secrettext-for-credentials.md rule at the same location. See sample: secrettext-with-httpclient.bad.al.