Business Central 2023 wave 2 (BC23): Use SecretText type to protect credentials and sensitive textual values from being revealed (New SecretText type)

Dynamics 365 Business Central

Hi, Readers.
The public preview for Dynamics 365 Business Central 2023 release wave 2 (BC23) is available. Learn more: Link.

I will continue to test and share some new features that I hope will be helpful.

Use SecretText type to protect credentials and sensitive textual values from being revealed:

Business value:
With an increasing amount of integrations to external systems, it’s not uncommon in AL code to work with secrets such as credentials and other sensitive textual values. Given the need to protect these from being revealed through debugging, the latter has often been blocked through resource exposure policies, at the cost of easy troubleshooting. To support enabling debugging, while protecting credentials and other sensitive textual values from being revealed, we are introducing a new SecretText type for variables. In addition, some of the common scenarios in the system app will get support for passing in SecretText parameters for credentials—for example, the HttpClient and Isolated Storage types.

https://learn.microsoft.com/en-us/dynamics365/release-plan/2023wave2/smb/dynamics365-business-central/new-securetext-string-type-store-variable-secrets-that-should-not-be-debugged

A new type, SecretText, has been added to protect credentials and other sensitive textual values from being revealed through debugging. The declaration syntax will be similar to the Text data type, with the sole difference that it won’t support constraints on the length.

SecretText will be usable as a:

  • Variable value
  • Return value
  • Parameter value

Cannot limit the length.

When debugging, it will be displayed as ‘<HiddenValue>‘.

Its use will be limited to carrying, for example, credentials from the point of creation to the destination method. The destination method must accept a SecretText value. For example, Message Method.

Argument 1: cannot convert from ‘SecretText’ to ‘Text’

There are no problems in the new HttpRequestMessage.SetSecretRequestUri method and HttpContent.WriteFrom method.

Any text type will be assignable to the SecretText type as long as it can be converted to the Text type. The SecretText type encapsulates a Text type. If a Code or other text type is to be stored, it’ll be converted into the Text type.

A Dotnet string type will also be convertible to SecretText. However, a constant or other types won’t be assignable to a SecretText type.

Cannot implicitly convert type ‘Text’ to ‘SecretText’

But you can add a Format Method to solve it.

For exceptional cases where it must be used as a text, a built-in Unwrap method will be supported. This will only be usable when the project scope is on-premises. Given on-premises only, it will be allowed outside of boundaries of a procedure marked as NonDebuggable, but it will result in a warning, and can thus also be blocked through the use of a ruleset for specific projects. More details: How to set your custom Method (procedure) and Variable non-debuggable (NonDebuggable Attribute) and URLs in includeRuleSets

PS:
1. There is also the following method in SecretText type to determine whether it is empty.

procedure IsEmpty(): Boolean
Returns a value indicating whether the secret text contains any content.

2. Similar to Text.StrSubstNo(Text [, Any,…]) Method, SecretText type includes the following method.

procedure SecretStrSubstNo(String: Text, [Value1: SecretText, …]): SecretText
Replaces %1, %2, %3… and #1, #2, #3… fields in a string with the values you provide as optional parameters.

Initially, events won’t support SecretText parameters; however, triggers will. The latter scenario is to support the case of control add-ins like the OAuth control add-in to return the credentials in a secure container.

In the system app, HttpClient will get support for passing SecretText parameters—for example, for credentials.

In the following example, the return value and parameter will not be debuggable:

Great, give it a try!!!😁

Example source code:

    // The return value and parameter will not be debuggable
    procedure Send(ContentTxt: SecretText; Credential: SecretText; TargetUri: SecretText)
    var
        Request: HttpRequestMessage;
        Response: HttpResponseMessage;
        Client: HttpClient;
        Headers: HttpHeaders;
        Content: HttpContent;
    begin
        Request.SetSecretRequestUri(TargetUri);
        Content.WriteFrom(ContentTxt);
        Request.GetHeaders(Headers);
        Headers.Add('Authorization', SecretText.SecretStrSubstNo('Bearer %1', Credential));
        Request.Content := Content;
        Client.Send(Request, Response);
    end;

PS: It is also mentioned in AL Language extension changelog Version 12

Awesome feature. Give it a try!!!😁

END

Hope this will help.

Thanks for reading.

ZHU

コメント

Copied title and URL