New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paket latest version 401 Unauthorized #1469

Closed
dustinmoris opened this Issue Feb 11, 2016 · 25 comments

Comments

Projects
None yet
3 participants
@dustinmoris

dustinmoris commented Feb 11, 2016

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 Paket.Utils.getXmlFromUrl@282-6.Invoke(String message)
   at Paket.Utils.getXmlFromUrl@271-5.Invoke(Exception _arg2)
   at Microsoft.FSharp.Control.AsyncBuilderImpl.callA@851.Invoke(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:

image

image

When I download Paket version 2.36.7 it works.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

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

Member

forki commented Feb 11, 2016

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

@dustinmoris

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris Feb 11, 2016

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.

dustinmoris commented Feb 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

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

Member

forki commented Feb 11, 2016

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

@dustinmoris

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris Feb 11, 2016

Okay, I'll have a look...

dustinmoris commented Feb 11, 2016

Okay, I'll have a look...

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

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

Member

forki commented Feb 11, 2016

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

@dustinmoris

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris Feb 11, 2016

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. -.-

dustinmoris commented Feb 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

what package?

Member

forki commented Feb 11, 2016

what package?

@dustinmoris

This comment has been minimized.

Show comment
Hide comment

forki added a commit that referenced this issue Feb 11, 2016

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

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

Member

forki commented Feb 11, 2016

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 comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris Feb 11, 2016

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>.$VersionRange.failParse@143-1.Invoke(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 Paket.NuGetV2.getDetailsFromNuGetViaOData@226-9.Invoke(Unit unitVar)
   at Microsoft.FSharp.Control.AsyncBuilderImpl.callA@851.Invoke(AsyncParams`1 args)
Paket failed with:
        Couldn't get package details for package Darkseid 0.3.0 on https://nuget.org/api/v2.
...

dustinmoris commented Feb 11, 2016

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>.$VersionRange.failParse@143-1.Invoke(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 Paket.NuGetV2.getDetailsFromNuGetViaOData@226-9.Invoke(Unit unitVar)
   at Microsoft.FSharp.Control.AsyncBuilderImpl.callA@851.Invoke(AsyncParams`1 args)
Paket failed with:
        Couldn't get package details for package Darkseid 0.3.0 on https://nuget.org/api/v2.
...
@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

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

Member

forki commented Feb 11, 2016

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

@dustinmoris

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris Feb 11, 2016

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 commented Feb 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris Feb 11, 2016

okay, makes sense re parsing error

dustinmoris commented Feb 11, 2016

okay, makes sense re parsing error

@domaslasauskas

This comment has been minimized.

Show comment
Hide comment
@domaslasauskas

domaslasauskas Feb 11, 2016

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?

domaslasauskas commented Feb 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

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

Member

forki commented Feb 11, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

is there a way for me to reproduce?

Member

forki commented Feb 11, 2016

is there a way for me to reproduce?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 11, 2016

Member

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

Just tried against myget and it works fine.

Member

forki commented Feb 11, 2016

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 added a commit to domaslasauskas/Paket-issue-1469 that referenced this issue Feb 12, 2016

@domaslasauskas

This comment has been minimized.

Show comment
Hide comment
@domaslasauskas

domaslasauskas Feb 12, 2016

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.

domaslasauskas commented Feb 12, 2016

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

This comment has been minimized.

Show comment
Hide comment

dustinmoris commented Feb 12, 2016

Thanks @domaslasauskas!

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 12, 2016

Member

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?

Member

forki commented Feb 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 12, 2016

Member

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

Member

forki commented Feb 12, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 12, 2016

Member

ok found the bug. will fix later today

Member

forki commented Feb 12, 2016

ok found the bug. will fix later today

forki added a commit that referenced this issue Feb 12, 2016

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 12, 2016

Member

please try with 2.50.6

Member

forki commented Feb 12, 2016

please try with 2.50.6

@domaslasauskas

This comment has been minimized.

Show comment
Hide comment
@domaslasauskas

domaslasauskas Feb 12, 2016

It's fixed now, thanks!

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

domaslasauskas commented Feb 12, 2016

It's fixed now, thanks!

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

@forki forki closed this Feb 12, 2016

@dustinmoris

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris commented Feb 12, 2016

cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment