Open guybedford opened 8 years ago
@mlaccetti may be able to post the .npmrc
structure to replicate.
.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.
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?
@guybedford The registry in the package.json:
"publishConfig": {
"registry": "https://10.64.16.137/repository/internal-npm/"
}
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.
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
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.
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!
Ok, so we should just never auth unless alwaysAuth
is set from what it seems.
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?
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.
I think these are the rules for setting the creds:
alwaysAuth
set to trueFrom 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.
Thanks, that's an excellent summary - we can go ahead and implement exactly that then.
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?
@lj1000 this may have been a regression in 0.26.14. Did you try 0.26.13?
thanks guybedford. installed jspm@0.16.13 locally and now works.
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
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.)
Hi I recently tried 0.17.0-beta.47 and still having this issue. has there been any progress incase im missing something.
@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.
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
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.