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?
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.
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.
Have you re-started LINQPad after changing the username/password? (This is required by the NuGet API)
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.
I still can't reproduce this error. My devops feed URI looks like this:
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.
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!
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.
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.
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)
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: Basic realm="https:/host.name.com/tfs"
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.
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.
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.
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 -
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.
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.
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.
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.
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 -
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.
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'.
Try with 7.3.8 and let me know how you get along.
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 -
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.