Paket latest version 401 Unauthorized

[dustinmoris]

When I use the latest version (2.50.2.0) I get an error when updating my packages:

Source 'http://teamcity.*****' exception: System.Exception: Could not retrieve data from http://teamcity.*****/odata/Packages(Id='****',Version='1.0.0.0')
 Message: One or more errors occurred.
 Details: The remote server returned an error: (401) Unauthorized.
   at [email protected](String message)
   at [email protected](Exception _arg2)
   at [email protected](AsyncParams`1 args)
Paket failed with:
        Couldn't get package details for package **** 1.0.0.0 on http://teamcity.*****.

It seems like Paket stops sending the Authorization header:

When I download Paket version 2.36.7 it works.

[forki]

Can you try to find the last version that still works? Would makes things easier for us to track down

[dustinmoris]

Oh man :( That's a lot of versions in between...
The question is, am I the only one who is getting this? Because you can see that in the 2nd screenshot the Authorization header is not being sent. Should it not be easy to check in the code where the auth header gets set and what the reason could be for it to be ignored? Or at least check the history of that file. Would be quicker than me having to go through a ton of versions with trial and error.

[forki]

Can you try to find the please also try to run "paket update -f" so that we know it's not cache related

[dustinmoris]

Okay, I'll have a look...

[forki]

I ask because AFAIK our teamcity still works, so there must be something subtle. @agross how about you?

[dustinmoris]

As I am trying to narrow it down I came across another issue now. When I revert back to v2.36.7 I get a parse error from a public NuGet packge on NuGet.org, which is completely unrelated to my initial issue.

I will continue to narrow down the original issue, but it seems to me that the package pulling is extremely unstable. Makes me wonder if there was a good reason to completely reinvent everything instead of using the well tested and working NuGet client for some of the work like getting package information which would be the same for both products. -.-

[forki]

what package?

[dustinmoris]

https://www.nuget.org/packages/Darkseid/

[forki]

facaf22 seems to work. How can I reproduce that? Is the parsing a real error or does only one of the intermediate proctols fail?

[dustinmoris]

This is how I get the parsing error:

paket.dependencies

source https://nuget.org/api/v2

nuget Darkseid

paket.lock

NUGET
  remote: https://nuget.org/api/v2
  specs:
    Darkseid (0.2.0)

Then I run

paket.bootstrapper.exe 2.36.7
paket update Darkseid

And I get:

Paket version 2.36.7.0
Updating Darkseid in C:\Dev\test\paket.dependencies group Main
Resolving packages for group Main:
 - Darkseid 0.3.0
Paket failed with:
        Couldn't get package details for package Darkseid 0.3.0 on https://nuget.org/api/v2.

With verbose on:

...
Source 'https://nuget.org/api/v2' exception: System.Exception: unable to parse (, )
   at <StartupCode$Paket-Core>[email protected](String message)
   at <StartupCode$Paket-Core>.$VersionRange.parseRange@142(FSharpRef`1 prereleases, String text)
   at Paket.VersionRequirement.Parse(String text)
   at Paket.NuGetV2.split@158-1(String d)
   at Paket.NuGetV2.parseODataDetails[a](String nugetURL, PackageName packageName, a version, String raw)
   at [email protected](Unit unitVar)
   at [email protected](AsyncParams`1 args)
Paket failed with:
        Couldn't get package details for package Darkseid 0.3.0 on https://nuget.org/api/v2.
...

[forki]

ah so that's only in older version and already fixed. Yes NuGet.org changed their dependencies format one night...

[dustinmoris]

It also seems that the original issue which I reported happened after 2.36.7, because when I use the next version 2.37.0 I get the same issue as with the very latest.

I was looking at the changes 2.36.7...2.37.0 and there is quite some stuff that happened there so I need to have a closer look

[dustinmoris]

okay, makes sense re parsing error

[domaslasauskas]

The private package source in question is a private ProGet instance, but I don't think it makes a different as long as package source requires authentication.

I've tried debugging this issue. Not sure if that's the cause, but I've tracked missing authentication to PackageResolver.getCompatibleVersions where availableVersions are resolved from LockFile which parses sources with authentication as None. However, it's not so obvious where this bug was introduced looking at 2.36.7...2.37.0 changes.

Should Paket try to apply authentication to such sources at a later stage when downloading the package?

[forki]

yes getcompatibleversion should only use sources with proper authentication.
We need to find the place where it lost the authentication

[forki]

is there a way for me to reproduce?

[forki]

but I don't think it makes a different as long as package source requires authentication.

Just tried against myget and it works fine.

[domaslasauskas]

I've started new private ProGet instance, and was able to reproduce this issue there.

While NonExistingPackage.* packages don't actually exist in this private package source, it's still possible to reproduce the issue, because Paket update fails with Unauthorized 401 response from server thus reproducing the bug.

You can reproduce the bug by running build.cmd, build.sh, or paket.exe update nuget Darkseid version 0.3.0. Hope this helps.

[dustinmoris]

Thanks @domaslasauskas!

[forki]

thanks for createting a repro. but shouldn't https://github.com/domaslasauskas/Paket-issue-1469/blob/master/paket.dependencies#L2 contain username and pw so that I could theoretically get in?

[forki]

but If I add this then I think I can reproduce and have an idea of what's going wrong.

[forki]

ok found the bug. will fix later today

[forki]

please try with 2.50.6

[domaslasauskas]

It's fixed now, thanks!

Re: credentials - we don't store credentials in paket.dependencies, they are set using paket config add-credentials instead.

[dustinmoris]

cheers!