Open shenglol opened 4 years ago
@majastrz can produce this?
Yes, I had this happen to me as well.
@shenglol I think this is expected - PowerShell doesn't automatically change your selected subscription after a logn, unless you specify a subscription. You would need to select the new context after logging in. This is because you are allowed to be logged in simultaneously as multiple users against multiple environments.
Do you think this behavior should change, or are you seeing something different?
@markcowl it's weird that you can do Login-AzAccount -Environment foo
and it won't actually use that environment to make calls unless you do extra steps to force it. (Is this behavior documented somewhere?)
@markcowl I think I'm with @majastrz . My expectation is that we don't have to run Disconnect-AzAccount
before running Connect-AzAccount -Environment foo
.
Besides, I think the real issue is that it does work if foo is one of the built-in environments. Notice that in the Steps to reproduce section, the last cmdlet Connect-AzAccount -Environment Dogfood
successfully changed the environment while the previous one Connect-AzAccount -Environment Canary
didn't (Canary is a custom environment that only changes one URL).
@shenglol @majastrz I believe this is an issue with context name clashing -- by default, contexts are generated with the name {subscriptionName} ({subscriptionId}) - {accountId}
, and typically this is unique enough (and short enough 😁) to prevent duplicate contexts, but there are cases like this where the environment is different, but the subscription and the account are the same, so the cmdlet thinks that this context already exists and doesn't add it to the context list or change the current context to the new one.
@msJinLei @markcowl I think the right thing to do here is to either (1) include the environment in the context name, (2) override an existing context with the same name when the user runs Connect-AzAccount
, or (3) throw an exception when it determines that it cannot change the default context to the new one created by Connect-AzAccount
.
@dcaro for priority
@shenglol @majastrz I believe this is an issue with context name clashing -- by default, contexts are generated with the name
{subscriptionName} ({subscriptionId}) - {accountId}
, and typically this is unique enough (and short enough 😁) to prevent duplicate contexts, but there are cases like this where the environment is different, but the subscription and the account are the same, so the cmdlet thinks that this context already exists and doesn't add it to the context list or change the current context to the new one.@msJinLei @markcowl I think the right thing to do here is to either (1) include the environment in the context name, (2) override an existing context with the same name when the user runs
Connect-AzAccount
, or (3) throw an exception when it determines that it cannot change the default context to the new one created byConnect-AzAccount
.
That makes sense. Thanks for the explanation @cormacpayne!
Description
Using
Connect-AzAccount -Environment
to switch to a custom environment doesn't really change the environment. I had to disconnect and re-connect again to make it take effect. However, changing to a built-in environment seemed to work as expected.Steps to reproduce
Environment data
Module versions
Debug output
Error output