_auth being set causing 500 error on scopes

[guybedford]

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]

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

[mlaccetti]

.npmrc

strict-ssl=false
init.author.name=Michael Laccetti
[email protected]
init.author.url=https://laccetti.com/
[email protected]
_auth="ohdontyouwishihadleftthis"

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

[guybedford]

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]

@guybedford The registry in the package.json:

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

[guybedford]

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]

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]

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]

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]

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

[guybedford]

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]

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]

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]

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

[lj1000]

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]

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

[lj1000]

thanks guybedford.
installed [email protected] locally and now works.

[guybedford]

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]

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]

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

[guybedford]

@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]

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