Continuous prompting for credentials on Linux / VS Code about artifacts-credprovider HOT 22 CLOSED

Declaring the ARG in the Dockerfile and using the following worked:

docker build -t ${IMAGE} --build-arg VSS_NUGET_EXTERNAL_FEED_ENDPOINTS .

But I'm still not sure why assigning the value of the env var to the build arg didn't work.

from artifacts-credprovider.

Thanks Zach. I'll forward this info to my client and request confirmation on authz.

from artifacts-credprovider.

It is also a bit odd that it never gives up in that case in interactive mode - I could see an argument that it eventually should.

It actually will if you don't provide an auth response within the 90 secs, but, imo, violates the principle of least astonishment.

from artifacts-credprovider.

. I think that nuget would need to show the error (403 in this case) but doesn't at that point as far as I can tell, even with higher verbosity

Skimming the code, it looks like we don't.
I think NuGet should look into fixing this if at all possible. I can't really judge the complexity of this without a longer investigation.

As far as NuGet telling the provider what the error was, that'd require some API changes in both the nuget libraries and the nuget-plugin protocol.
Doable, just would have extra considerations.

Personally I think that NuGet communicating the reason behind the cred request to the user is the right approach.

Update: NuGet/Home#8515

from artifacts-credprovider.

Hi @bcraun,

I just tried to reproduce this on an Ubuntu 19.04 docker image with the latest cred provider, and was unfortunately unable to.

Could you please run the following command to run the credential provider directly and hopefully gather a bit more information?

dotnet ~/.nuget/plugins/netcore/CredentialProvider.Microsoft/CredentialProvider.Microsoft.dll -RedactPassword -Verbosity Debug -Uri {your package source uri}

Of course, feel free to continue redacting any sensitive information, but it would be useful to also know:

• Are you using a MSA (personal) or AAD (work/school) identity?
• Are you using pkgs.dev.azure.com/{org}, or {org}.pkgs.visualstudio.com URLs?

You can also try taking a backup of the credential cache folder ~/.local/share/MicrosoftCredentialProvider/ and then deleting it, and then running the restore or credprovider again.

from artifacts-credprovider.

Hi Zach,

• I am using my company-provided AAD account which was delegated access to the Azure DevOps project by my client
• I am using a pkgs.dev.azure.com/{org} URI and I have been granted Owner permissions by my client.

I deleted the cache folder and used the command you provided to call the .dll directly and, although it did not enter the endless authentication loop as before, the subsequent dotnet restore still returned the same error as before as shown in the screenshot.

Here's what I'm seeing now:

Thank you for your help.

from artifacts-credprovider.

From that error it looks like the true issue isn't with authentication, it's authorization/permissions. Can you confirm in the feed's settings UI that you have permissions on that feed?

Based on that, I think the actual behavior of the cred provider is actually somewhat reasonable: The credprovider is giving you another chance to try a different identity that does have permission... but really needs to have an error message indicating that rather than just showing another prompt.

I'll attempt to reproduce this tomorrow and see if we can improve/add an error message.

from artifacts-credprovider.

It is also a bit odd that it never gives up in that case in interactive mode - I could see an argument that it eventually should.

from artifacts-credprovider.

I have verified credentials with my client and I am actually an Owner. I also verified my access tokens in Azure DevOps

I am seeing the same results every time and do not understand how auth/authz wouldn't be working for me.

Any help would be appreciated as this is now a blocking issue.

from artifacts-credprovider.

What do you see when you try to use the UI for that organization and browse to the feed?

from artifacts-credprovider.

One other thought - any chance you're licensed as a "Stakeholder" user? We just discovered yesterday a permissions issue with stakeholder licenses we're fixing.

from artifacts-credprovider.

That was it. My access level was Stakeholder. I changed myself to Basic, re-ran the command with a new token and dotnet restore worked.

from artifacts-credprovider.

Glad you were able to work around that and sorry about the issue. +@pspill as FYI since he was investigating that issue.

from artifacts-credprovider.

Is there a timeframe for a fix as my client will need to purchase more Basic licenses immediately?

from artifacts-credprovider.

We've moved up the priority on the stakeholder permissions bug and are investigating at this moment. No ETA yet.

Since until this is resolved helping you work around it involves sensitive account information: If your client has a support agreement, could they please open a support request? Also, could you and/or them please email {myusername} [at] microsoft.com with any relevant information such as organization name.

from artifacts-credprovider.

Before buying a new Basic license please contact us - we should be able to help you work around this immediately.

from artifacts-credprovider.

Back to the original issue in the credprovider - while we could add a message to the effect of "The previous credentials were invalid, re-obtaining credentials" before showing a new prompt, nuget doesn't actually tell the credprovider why they were rejected. I think that nuget would need to show the error (403 in this case) but doesn't at that point as far as I can tell, even with higher verbosity. Thoughts @dtivel @nkolev92?

from artifacts-credprovider.

The credential provider can provide credentials that are generated a few different ways:

1. Interactively (via a device code prompt (on windows also via a UI)
2. Via environment variables such as VSS_NUGET_EXTERNAL_FEED_ENDPOINTS
3. [windows only] auto-magically via windows integrated authentication
4. Cached, previously generated by one of the above

In Azure Pipelines, we use #​2: We populate environment variables with a token generated by the build itself. If you're using Bitbucket pipelines, I assume that if it's already working outside a container it likely means you (or someone) has done something similar and likely set VSS_NUGET_EXTERNAL_FEED_ENDPOINTS.

To get auth working within a docker container, you'll need to propagate that environment variable into the container.

Let me know if any of that doesn't make sense or doesn't match your setup.

from artifacts-credprovider.

Yes I am using the VSS_NUGET_EXTERNAL_FEED_ENDPOINTS env var that's working in the standalone build so I'm not sure why it's not working. Would dotnet publish behave differently than dotnet build or dotnet restore?

I also tried prepending the env var to dotnet publish with no success.

VSS_NUGET_EXTERNAL_FEED_ENDPOINTS=$VSS_NUGET_EXTERNAL_FEED_ENDPOINTS dotnet publish -c Release *.csproj --output /home/site/wwwroot

from artifacts-credprovider.

dotnet publish implicitly does a build (which implicitly does a restore); it should be identical from an auth perspective.

Are you absolutely sure that the variable is correctly populated in the container? e.g. if you add a RUN echo $VSS_NUGET_EXTERNAL_FEED_ENDPOINTS, do you get what you expect?

If not: I'm not familiar with Bitbucket Pipelines - are you the one invoking the container build? Any reason not to use ARG with --build-arg rather than ENV?

from artifacts-credprovider.

Yes, I'm seeing that if I directly assign the JSON value of the env var to VSS_NUGET_EXTERNAL_FEED_ENDPOINTS in the Dockerfile it works so it has to be something about the propagation of the repo variable.

from artifacts-credprovider.

Yes, I believe that using ENV in that manner won't work, and that you likely want to make it an ARG and run docker build ... --build-arg VSS_NUGET_EXTERNAL_FEED_ENDPOINTS=$VSS_NUGET_EXTERNAL_FEED_ENDPOINTS (or the literal value if not set in the host environment)

from artifacts-credprovider.