💡 Sept. Tip => use case input fields can be sensitive too

Yesterday, we saw that even use cases can be sensitive. Like use cases, individual input fields can also be defined as "sensitive".

We can do it in two different ways.

The first one is at the data type level. For instance, TPassword is a built-in type that is sensitive for obvious reasons.

export class TPassword extends TString<Password> {
    // ...
    public override isSensitive(): boolean {
        return true;
    }
    // ...
}

So is TApiKey.

The second one is at the use case input field definition. For instance, a field can have a "regular" data type but be considered "sensitive" (e.g. a TURL containing a secret token in a query param during an OAuth flow).

In this case, like for use cases, we can use the sensitive property on UCInputFieldDef.

export const AuthenticateToStravaStep2UCD: UCDef<
    AuthenticateToStravaStep2Input,
    AuthenticateToStravaStep2OPI0
> = {
    // ...
    io: {
        // ...
        i: {
            fields: {
                clientId: {
                    type: new TExternalServiceId(),
                },
                clientSecret: {
                    type: new TApiKey(),
                },
                url: {
                    sensitive: true,
                    type: new TURL(),
                },
            },
        },
        // ...
    },
    // ...
};

The fact that a use case input field is sensitive is used in different ways in the targets.

In a CLI target, instead of passing the field in the command line, we would be prompted to enter it dynamically (like in the mysql command for example). This way, the "sensitive" field value does not remain in clear in the history.

In a GUI target (web or mobile), we would have an ad-hoc text input (e.g. an <input type="password" /> in web or a <TextInput secureTextEntry={isSensitive} /> in react-native).

Voilà c'est tout.