StingyJack
commented
5 years ago I'll take a prompt for credentials over more TF30063 errors.
Open acangialosi opened 5 years ago
StingyJack
commented
5 years ago I'll take a prompt for credentials over more TF30063 errors.
nkolev92
commented
4 years ago @karann-msft The AzDO issue was assigned to you for specing, so assigning the GH counterpart as well.
nkolev92
commented
4 years ago Notes from a discussion between myself & @acangialosi
Visual Studio is moving away from the auto prompt authentication flow. When authenticated resources are requested, users are frequently presented with a dialog that might not have enough context about the intent.
The approach is changing to a gesture driven approach. Only an explicit customer gesture should cause a prompt.
NuGet's authentication scenarios are resource driven. The 2 scenarios are authenticate at restore time (either on Build/when solution loads) and opening the Package Manager UI. Worth noting is that NuGet currently defers the authorization flow to the feed providers (Azure Devops/MyGet etc.).
NuGet should ensure that the customer is not presented with prompts without context. In the Package Manager UI, NuGet should be able to display a bar/visual indicator that the customer needs to authenticate. In the restore/build flow a similar approach should be investigated.
Scenarios that need to be considered but can't be fleshed out without a more detailed design.
acangialosi
commented
4 years ago Speaking to the user experience notifications should appear in the closest point of context in the ide. In cases where the auth failure happens and the user is in the package management ui then the status and command to reauth should appear in that ui. If the auth failure happens as a result of a background process then an infobar would be an appropriate solution.
rrelyea
commented
4 years ago We'll need to investigate the multiple accounts scenario for codespaces as part of this as well.
kartheekp-ms
commented
2 years ago @acangialosi - Sorry for the direct ping on this old thread. Recently we closed https://github.com/NuGet/Home/issues/11581 and I found this one searching for issues with label Authentication. The new sign in prompt for NuGet authentication to private Azure DevOps feeds now displays NuGet {feedname} needs your credentials text to help customers to pick the correct account for authentication. In this text NuGet refers to the feature name & feedname refers to the package source that needs authentication.
It's a design option to make that a blocking or non-blocking notification but the experience should never go directly to a sign in prompt.
The current user experience is AZ DO credential provider displays a sign-prompt in VS when NuGet invokes them during credentials acquisition. I have not tried yet, but I expect similar experience to third party VS Credential providers such as MyGet.
Given that we added some additional context to auth sign-in prompt in VS 2022, do you think the current experience violates any guidelines?
Design guidelines for integrating with VS' identity say that VS should never auto-prompt for credentials. There dozens of connected experiences in VS from nuget package restore to symbol resolution, and many others that can trigger an authenticated request for users. We learned in earlier releases that having features prompt for credentials automatically had a poor impact on the user experience as users saw multiple prompts to sign in back to back without any context about what is triggering the sign in prompt. As all connected experiences are required to present a status with a command where users can enter (re-enter credentials). It's a design option to make that a blocking or non-blocking notification but the experience should never go directly to a sign in prompt.