Skip to content
This repository has been archived by the owner on Feb 18, 2024. It is now read-only.

_auth being set causing 500 error on scopes #106

Open
guybedford opened this issue Nov 30, 2015 · 21 comments
Open

_auth being set causing 500 error on scopes #106

guybedford opened this issue Nov 30, 2015 · 21 comments
Labels

Comments

@guybedford
Copy link
Member

Not sure what the exact credentials were, but with a case where npm was configured for an organization (I'm not sure if it was running against the public registry or the organization mirror), but @reactive/rxjs apparently was giving a 500 error on lookup.

@guybedford guybedford added the bug label Nov 30, 2015
@guybedford
Copy link
Member Author

@mlaccetti may be able to post the .npmrc structure to replicate.

@mlaccetti
Copy link

.npmrc

strict-ssl=false
init.author.name=Michael Laccetti
init.author.email=mlaccetti@uncharted.software
init.author.url=https://laccetti.com/
email=mlaccetti@uncharted.software
_auth="ohdontyouwishihadleftthis"

We have a private registry (based on Nexus 3) for our internal libraries; that's what the auth is for.

@guybedford guybedford changed the title Organization credentials causing 500 error on scopes _auth being set causing 500 error on scopes Dec 1, 2015
@guybedford
Copy link
Member Author

I take it the _auth will not be valid on npm itself here then?

Where is the reference to the private registry itself handled? In a local configuration file?

@mlaccetti
Copy link

@guybedford The registry in the package.json:

"publishConfig": {
    "registry": "https://10.64.16.137/repository/internal-npm/"
  }

@guybedford
Copy link
Member Author

I guess what we need to do here is see if npm is really just ignoring the 500 response, and then disabling the auth, and if so then we can just copy that behaviour (retrying and then not using auth for subsequent requests). Otherwise if there is some way npm knows specifically not to use the invalid auth, then we should make sure to implement that mechanism.

@mlaccetti
Copy link

Looks like it does some other checks:

npm sill fetchPackageMetaData @reactivex/rxjs
npm sill fetchNamedPackageData @reactivex/rxjs
npm sill mapToRegistry name @reactivex/rxjs
npm sill mapToRegistry scope (from package name) @reactivex
npm verb mapToRegistry no registry URL found in name for scope @reactivex
npm sill mapToRegistry using default registry
npm sill mapToRegistry registry https://registry.npmjs.org/
npm sill mapToRegistry uri https://registry.npmjs.org/@reactivex%2frxjs
npm verb request uri https://registry.npmjs.org/@reactivex%2frxjs
npm verb request no auth needed

@guybedford
Copy link
Member Author

Excellent, thanks - so we just need to find out what exactly it is that lets npm know that no auth is needed.

There doesn't seem to be any header or metadata present informing this for this specific request, so it must be based on getting a different type of response for scoped packages that are private and do need auth, which would be worth investigating with a test case further what metadata that provides this with.

@mlaccetti
Copy link

Looks like they perform a few checks to see if they should auth - https://github.com/npm/npm-registry-client/blob/master/lib/request.js#L60 - basically, never auth!

@guybedford
Copy link
Member Author

Ok, so we should just never auth unless alwaysAuth is set from what it seems.

@guybedford
Copy link
Member Author

The only thing that confuses me about that is does that mean that alwaysAuth HAS to be set for private registries that are restricted, or will npm respond to the 500 and then auth?

@guybedford
Copy link
Member Author

Ok it is definitely not retrying for an unauthed response, so perhaps it really just is alwaysAuth that indicates this, but surely that would mean that private setups would get unauthorized responses, even when credentials are set, just if they forgot to set alwaysAuth, which sounds like it must be wrong to assume that is the workflow.

@mlaccetti
Copy link

I think these are the rules for setting the creds:

  • alwaysAuth set to true
  • using PUT/POST/DELETE

From what I have read, if you have a private registry that requires auth for reading, you have to set alwaysAuth to true. No other way of setting auth for a GET.

@guybedford
Copy link
Member Author

Thanks, that's an excellent summary - we can go ahead and implement exactly that then.

@lj1000
Copy link

lj1000 commented Oct 31, 2017

running into this issue. currently using jspm 0.16.53.
my .npmrc file needs to have _auth=myencodedcredentials to allow me to publish to a private npm repo. when i run jspm install i get the err error looking up somepackagename. I have to remove the _auth=myencodedcredentials to get jspm install working then replace it once complete.

has any progress been made on this?

@guybedford
Copy link
Member Author

@lj1000 this may have been a regression in 0.26.14. Did you try 0.26.13?

@lj1000
Copy link

lj1000 commented Oct 31, 2017

thanks guybedford.
installed jspm@0.16.13 locally and now works.

@guybedford
Copy link
Member Author

Thanks for confirming @lj1000. Ok it may be necessary to revert the previous change then, unless we can get a fix in soon.

//cc @xemle

@lj1000
Copy link

lj1000 commented Oct 31, 2017

sorry guybedford.
my mistake it hasn't solved the issue still not loading (i had accidentally tried it without the _auth=myencodedcredentials arrrr put them back in and it cant install again.)

@lj1000
Copy link

lj1000 commented Jan 22, 2018

Hi I recently tried 0.17.0-beta.47 and still having this issue. has there been any progress incase im missing something.

@guybedford
Copy link
Member Author

@lj1000 it seems this may have been a regression in 0.30.3. Try installing jspm-npm at exactly 0.30.2 in the node_modules folder of jspm and see if that helps? If so we can potentially revert #165.

@lj1000
Copy link

lj1000 commented Mar 14, 2018

i removed the installed jspm-npm folder and installed the 0.30.2 version. still getting same error

Error on lookup for npm:mypackage
Invalid status code 403

but works fine with npm i mypackage

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants