Enhancement add cliEntraAppId and cliEntraAppTenant configurations settings for cli config commands

[mkm17]

As discussed in this thread #5985 (comment)

The aim of the task is to add the cliEntraAppId and cliEntraAppTenant options to the list of available settings for: cli config get , cli config list , cli config reset , cli config set.

Later the new options will be utilized in cli app add command.

The importance of the app ID setting would be as follows:

1. CLIMICROSOFT365_ENTRAAPPID
2. CLIMICROSOFT365_AADAPPID (obsolete)
3. cliEntraAppId (new setting option)
4. the default one

The importance of the tenant setting would be as follows:

1. CLIMICROSOFT365_TENANT
2. cliEntraAppTenant (new setting option)
3. "common"

[waldekmastykarz]

We should use the new config options wherever we refer to config.cliEntraAppId. I suggest that the value configured in the CLI takes precedence over env var (so the order for the app ID is 3, 1, 2, 4 and tenant 2, 1, 3)

[mkm17]

ok, noted. You can assign me to this task since I've already made some research on this topic.

[milanholemans]

Currently, all our config settings are not tenant-bound. If we implement this, it will clash when switching connections (when switching to another tenant). I'm wondering if this is problematic here.

[mkm17]

Hi, @milanholemans Isn't it similar to using the 'CLI MICROSOFT365 TENANT' option?

Perhaps it's a helpful clue. There's a distinction when a user sets 'CLI MICROSOFT365 TENANT' parameter themselves and encounters an issue, versus when issues arise from setting it the 'supported way' in background, using cli app add (as mentioned in the task).

[milanholemans]

Yes, but CLIMICROSOFT365_TENANT is an environment variable.
If we introduce this both as an environment variable and config setting, I don't see the point anymore why we still support it as environment variable.

[mkm17]

Hi @milanholemans, The new configuration setting will be only used for cli app add to assign the newly created app for CLI purposes.
I agree that it would be best to use only one environment or configuration setting, but if I'm not mistaken, there's no possibility to assign environment settings from the code.

If you're referring only to the cliEntraAppTenant option, perhaps we can remove it. When we create a new app with cli app add, it's created under the current tenant scope, so maybe we don't need to set the tenant in the configuration settings.

But to summarize, we have a few options to choose from:

1. Simply don't add these configuration options and inform a user after running cli app add to set the configuration themselves using CLIMICROSOFT365_ENTRAAPPID and CLIMICROSOFT365_TENANT.
2. Add only one configuration option, cliEntraAppId, and assume that the tenant configuration is correct.
3. Add both options as described at the beginning.

What do you think @milanholemans ?

[milanholemans]

I have no idea whether or not you can update an environment variable to be honest. I'm just a bit concerned that we are creating now 2 paths to achieve the same thing, which I don't really like. In my humble opinion, we should either get rid of the env variables or just not set the app ID and tenant ID of the new app registration at all. Currently, I'm leaning towards the latter.

[mkm17]

@milanholemans I suppose removing environment variables is no longer an option since they are currently being used by users.

Ok, I believe the solution for cli app add would be to provide a message in the documentation on how to set environment variables. Not a perfect solution, but it won't cause any harm or confusion.

@waldekmastykarz Would it be ok?

[milanholemans]

@milanholemans I suppose removing environment variables is no longer an option since they are currently being used by users.

If needed, we can remove them in the next major release.

Have you tried setting an environment variable like we do here?

cli-microsoft365/src/appInsights.ts

Lines 3 to 5 in 5f64790

	process.env.APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL = 'none';
	// prevents tests from hanging
	process.env.APPLICATION_INSIGHTS_NO_STATSBEAT = 'true';

Or is this not something persistent?

[mkm17]

@milanholemans Exactly, I have tried the same approach:

Unfortunately, the result is as follows.

In debugging, I can see that this value is assigned correctly, but perhaps it is valid only during the execution.