Azure devops nuget feeds

Mario

Hi

is there a way to connect to azure Devops nuget feeds? Tried username + access token as pasword and it didn't work for me (HTTP 401)

Cheers,

damiensawyer

... I just created an account here to ask exactly the same question :-)

JoeAlbahari

I've just tried it and it works for me. I created a PAT according to these instructions:

https://docs.microsoft.com/en-au/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=vsts

From LINQPad's NuGet package manager, I went to settings, and entered the PAT into the password field. The username can be anything, such as ID.

Mario

yeah PAT works. I can swear this is what i did before posting this question, must have been some other issue:/

droyad

A customer of mine just ran into this problem as well for a feed service I run. It looks like the settings in the %AppData%/Nuget/Nuget.config file where overriding the values entered in the LinqPad UI. The URLs had to be an exact match and "Use legacy search" was enabled.

craighead

Hi there. I was having this exact same problem. An SO from 2017 led me in the right direction. https://stackoverflow.com/questions/40514300/how-to-use-visual-studio-team-services-as-a-nuget-feed-in-linqpad

It seems like linqPad refuses to authenticate with the V3 URIs.
I've tried:
https://mycompany.pkgs.visualstudio.com/_packaging/Feed/nuget/v3/index.json
https://mycompany.pkgs.visualstudio.com/_packaging/Feed/nuget/v3
With "Use Legacy Search Engine (Nuget V2)" checked and unchecked.

Everything works with this URI:
https://mycompany.pkgs.visualstudio.com/_packaging/Feed/nuget/v2
and "Use Legacy Search Engine (Nuget V2)" checked.

It would be nice if LinqPad just worked with the V3 URIs. Perhaps I'm doing something wrong too?

JoeAlbahari

I can't reproduce this error with the V3 feed. However, after combing through the code, I've picked up a bug whereby the NuGet credentials can potentially be overridden by machine settings. Can you try the latest beta and let me know whether it makes any difference:

https://www.linqpad.net/Download.aspx#beta

wjvii

It started working for me when I switched to the new Azure urls starting with https://pkgs.dev.azure.com

Not sure why or if that was actually what made the difference for me but after changing from https://xyz.pkgs.visualstudio.com to https://pkgs.dev.azure.com it started working.

Hope this works for someone else too.

Powellze

I couldn't connect to Azure Devops Artifacts.
I did the following:

1. Added PAT as per instructions above
2. Put the PAT as password
3. Used the BETA

That worked for me - i couldn't access it any other way.

BusterSlim

Hi,

I still experience the problem with Linqpad 6.5.5. It throws me an exception Unauthorized.
I tried with several combinations it with the PAT, user name and password and none worked.

Does anybody experience the same issue?

CrossBound

I have recently switched to LinqPad 6 (6.7.5 x64) and I'm experiencing this issue. We have an on-prem Azure DevOps instance. I've created a PAT with all scopes. I created a nuget feed in LinqPad and left the username blank and the password is the PAT token. I keep getting the authentication 401 error.

CrossBound

FYI, I tested this and without changing the feed at all the feed works in LinqPad 5 but not 6. I get the 401 error in LinqPad 6.

JoeAlbahari

Have you re-started LINQPad after changing the username/password? (This is required by the NuGet API)

Kenni

Hi,
I can confirm that using PAT in LinqPad 6 (v6.8.3) doesn't work , but the exact same configuration works in LinqPad 5 (v5.41.00). I have tried different configurations (v2, v3, PAT with and without username etc.), but no luck - still gets a 401. I hope this gets fixed soon, as I would like to use C# 8 features.

JoeAlbahari

I still can't reproduce this error. My devops feed URI looks like this:

https://linqpad.pkgs.visualstudio.com/_packaging/doLINQPad/nuget/v3/index.json

The username box contains 'ID', although it seems anything can go here (as long as it's not blank).

The password box contains the PAT.

Note that you must restart LINQPad after editing the credentials - this is because the NuGet client library caches the credentials after they're first sent and there appears to be no way to clear that cache.

ordinaryorange

Had 401 error on v6.8.3 until I followed Joe's notes. 1. Ensure Id field has something in it, password is PAT. 2. Save. 3. Restart linqpad. All good!

Kenni

Hi,
I still can't get it to work (now running version 6.9.15). However, I have a few things to add.

I have both version 5 and 6 installed at the same time. Changes to "Package Source" in one seems to affect the other. It looks like I don't have to put anything in the "Username" and "Password" fields in version 5 for it to work. But I still get the 401 (Unauthorized) in version 6. So I think this problem might not have anything to do with the PAT (for me at least).

What I have noticed is that the source shown in the message is different from the source in "Package Source". In stead of "https://[base path]/_packaging/[feed name]/nuget/v3/index.json" I get a message saying that "Failed to retrieve metadata from source 'https://[base path]/_packaging/[some guid]/v3/query2/?q=...'".

So LinqPad v6 seems to try to contact a source it doesn't have access to, whereas v5 does not.

I don't know if this helps at all, but I hope it does.

ordinaryorange

Got 5 and 6 here too. Same v6 as you. Both work for me. My V6 is an XCopy deploy not an install, but I dont know if that makes any difference ?
In my nuget setup I have my source as https://xxxx.pkgs.visualstudio.com/_packaging/xxxx/nuget/v3/index.json, I have "ID" (without quotes) as the Username and Personal Access Token from AzDevops for password.

HTH

ulm

When used username != null but "ID" and Password=PAT as described above it worked.
Url = https://pkgs.dev.azure.com/[Project]/_packaging/[Project]/nuget/v3/index.json (see Azure own webpage)
Using LinqPad 6.12.4 (x64)

mjstrom

I am having the same access denied issue with Linqpad 7 and Azure Devops Server 2020 (the on-premise version). I followed the instructions about setting up a PAT but that doesn't fix the issue, I still get an error message like the following (hostname redacted) -

Unable to load the service index for source https://host.name.com/tfs/Development/_packaging/Internal/nuget/v3/index.json.

Response status code does not indicate success: 401 (Unauthorized).

I looked at the https traffic to the server and I can see the initial request for the feed followed by a 401 from the server. The server gives the following authentication options -

WWW-Authenticate: Bearer
WWW-Authenticate: Basic realm="https:/host.name.com/tfs"
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Linqpad is picking the Negotiate option and attempting to use window domain credentials instead of picking Basic and sending the PAT.

Authorization: Negotiate Tl...

Linqpad retries the Negotiate method several times but never tries to sent the PAT using Basic.

The nuget.exe command line , when configured with the PAT, picks Basic and sends the correct basic header -

Authorization: Basic SW...

As an aside, nuget.exe can also properly use Negotiate and authenticate without the PAT. I'm not sure why Linqpad can't also successfully use Negotiate.

ordinaryorange

I don't know much about the on prem version. I see calls to the cloud devops only requests Bearer, Basic & TFS-Federated. As a workaround does the on prem version have config options to control the feed authentication types ? I definitely sounds like LP's wrapper over nuget is not doing the right thing.

JoeAlbahari

That's interesting - it's unclear why Negotiate shouldn't work. However, if this is indeed the problem, a workaround should be possible. Try the LINQPad 7.3.6 beta:
https://www.linqpad.net/linqpad7.aspx#beta

I've added an option to the NuGet sources dialog to let you restrict authentication types:

If you enter basic into this box, it will tell the NuGet client to allow only basic authentication. Let me know if this helps.

mjstrom

The beta with Basic fixed the problem, thanks.

I went back and looked at the network traffic again and I think the problem with Negotiate is that the Username and Password from the UI are being passed as-is to the server. Azure Devops Server only accepts PATs with Basic authentication.

For example, with a username of ID and the PAT in the Password field the authentication header fields for Negotiate in the request decode (via Fiddler) to the following -

Domain: 
User: ID
Host: WorkStation

If I type actual windows domain username and password into the username and password fields then the Negotiate authentication works. For example, if my domain username was Domain\MJS then the following would be in the header.

Domain: Domain
User: MJS
Host: WorkStation

If I use my domain usename with the PAT without the Basic authentication type it does not work.

I assumed, incorrectly, that Linqpad would act like nuget.exe or visual studio and attempt to pass the logged in user's context to the server when presented with Negotiate from a server in the same domain. Maybe a nice to have feature would be the ability to elect to send current user ( CredentialCache.DefaultCredentials or CredentialCache.DefaultNetworkCredentials) when Negotiate is an option.

JoeAlbahari

Thanks for the info. I suspect the issue is the same as this:
https://stackoverflow.com/a/55245837

It's unclear to me exactly what the NuGet command-line is doing to make this work in your case (perhaps you have an environment variable set?), and how I could copy that behavior. What I might do instead is to use basic authentication as a fallback when credentials are supplied (without a domain name), so that when Negotiate fails, it will try again with Basic. This will ensure that it "just works", without needing to provide a text box for authentication types. I will also add a checkbox for windows default credentials.

JoeAlbahari

Try the 7.3.7 build - it now automatically applies basic auth if negotiate fails. There's also an option to use windows default credentials.

mjstrom

In the 7.3.7 build the "Use default windows credentials" is working but the PAT isn't working. Looking at the network traffic, I am only seeing a Negotiate attempt with the username and password and then a failure. I am not seeing an attempt to do basic authentication.

Could the "realm" that is included with the basic header be causing an issue?

WWW-Authenticate: Basic realm="https:/host.name.com/tfs"

For completeness, I testing the following methods -

• Use default windows credentials" - works
• Enter windows username and password in fields - works
• Username "ID" and password "PAT" - fails

mjstrom

One other note about the beta, trying to install (Add to Query) a package from a feed that is setup to use default windows credentials leads to an error.

---------------------------
LINQPad
---------------------------
Error downloading 'CsvHelper' - An error occurred while retrieving package metadata for 'CsvHelper.27.2.1' from source 'External'.

  - Response status code does not indicate success: 401 (Unauthorized).

Object reference not set to an instance of an object.



Additional warnings: An error occurred while retrieving package metadata for 'CsvHelper.27.2.1' from source 'External'.
---------------------------
OK   
---------------------------

JoeAlbahari

Try with 7.3.8 and let me know how you get along.

mjstrom

There are some glitches in saving the authentication options in the UI. If you don't put in a username or password the "Authentication" option isn't be preserved. For example, in the Nuget Settings dialog, click Add, enter a name, source, and select "Windows - default credentials". Click save then OK to close the dialog. Reopen the dialog and select the feed you just created and the Authentication option reverts back to "Basic / none".

I did test the following options with browsing and adding packages and they all worked properly -

• Basic with username ID and a PAT
• Windows with domain username and password entered
• Windows - default credentials

Auto-Detect works with a domain username and password but does not work with a PAT. But, since basic with a PAT works and the windows default credentials works, the auto-detect not working isn't an issue, at least for me.

Thanks for taking the time to look into the nuget issues and the quick turn arounds with the beta versions.