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

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.