Apparently it's possible for preferred_username to be like `foo@mybiz.com` while `email` is set to `foo@mybizemail.com`... This is the more correct ordering.
So, when you make a new session in the Microsoft Identity stack, depending on the scopes you pass in you might get:
* A token with a name & email
* A token with just a name
Additionally, Microsoft has like 3-4 concepts of essentially an "id" but depending on what you're trying to access, you might get a different value.
This historical behavior leads to 2 awkward things:
1. The account menu shows two accounts, one with name & email, one with just email.
2. The account menu shows two of the same accounts, but their underlying id is different
So, to fix this, we're just gonna lean on the labels. In other words, if there are two accounts that share the same label, then they will be grouped together.
The previous behavior was hurting the Azure Account folks and the Q# folks and with this change, I believe they both should be happy.
Interestingly enough, when I inherited this code, it use to do this, but I changed it to use the id as that seemed "more correct"... so it a way, this is reverting a change I did a while back.
Fixes https://github.com/microsoft/vscode/issues/184218
The idea here is... if a token is currently being refreshed, well then getting a token of those scopes should wait for that to finish.
Core has a really nice `SequencerByKey` for exactly this kind of thing, and so I've stolen that and started to organize the code with a `common` folder.
Oh, I also noticed we were sorting twice and fixed that to only sort once.
ref https://github.com/microsoft/vscode/issues/186693
This PR adds a ton more logging, a consistant format, and fixes the log levels of some.
Additionally, there are two small fixes that I have included:
* we were firing the `_sessionChangeEmitter` twice when a session was removed
* when processing updates from other windows, we returned instead of continued... thus were only processing the first account that was added in another window
* Use `@azure/ms-rest-azure-env` as official reference of endpoints
* Allow better configuration of custom clouds (these are new so it is ok to change the settings without migration)
Also clean up:
* querystring -> URLSearchParams (getting rid of a package dependency in the web)
* handle `workbench.getCodeExchangeProxyEndpoints` in one place
Before this change, every single window was writing to the same secret at basically the same time because they would all refresh the token and then attempt to store that refresh token.
I believe this was causing a few race condition bugs that users were seeing.
With this change we now so our best to have only 1 window store the session by relying on the window focused state.
If the window is focused or becomes focused, we will store the refresh token.
If the window detects that another window has stored something, we will not attempt to wait for focus to store something.
If nothing has happened, and it's been 5 hrs (+/- some seconds) go ahead and store it. This is the scenario of when a user has VS Code in the background for like ages but never goes to it.
ref #165115
ref #130893
ref #168485
* introduce log api in extension context
* separate registering output vs log channel
* Separate extension log channels in show logs command
* add logging error to embedder logger
* show extension log in the extension editor
* configure log level per extension
* change the order of log entries
* introduce logger
* align with output chanel
* revert changes
* fixes
