Allow authentication header to be passed-thru to upstream when resolving packages.

[samcday]

I love sinopia. It's shaping up to be like the swiss-army knife for bespoke npm registry setups.

Let me explain what this is for a little. We want to roll our own private NPM registry for our internal packages. However, we already have multiple sinopia proxies in place for different geographical locations. These proxies currently require no authentication, as they were just there to speed up resolving requests to the public NPM registry. Now that we want private NPM endpoints, we want developers to be able to continue using the "edge proxies" - but certain packages will split out to hit a different registry. When that happens, we want to be able to put sinopia into a sort of "dumb mode", in which its own ACL is ignored, but it forwards the request including any given authentication data to the upstream.

One of the primary reasons we want to do this is to avoid needing to roll authentication on every edge locations. Here's a naive example of how this PR would be useful:

Imagine this in your config.yaml:

packages:
  'private-*':
    allow_access: all
    auth_passthrough: true
    proxy: private-registry
  '*':
    proxy: npmjs

In the example above, this PR will ensure that sinopia doesn't do any ACL checks, but passes the inbound authentication header along to the private-registry.

An aside, part of this use-case is we're going to want to be able to completely disable resolved packages from upstream being persisted in local storage for certain package patterns. Is that currently possible? If not, I'll be submitting another PR for that :)

[rlidwka]

An aside, part of this use-case is we're going to want to be able to completely disable resolved packages from upstream being persisted in local storage for certain package patterns. Is that currently possible?

Yeah, you just set false as a storage (without the quotes, so yaml would parse at as a boolean, not as a string). See discussion in #85 .

But right now it sucks, I mean if sinopia doesn't store package info locally, and you fetch tarball from remote, it makes two requests instead of one. I don't know if it could be improved.

[rlidwka]

About the PR:

This looks like a footgun. Imagine if someone with credentials makes a request, then package gets cached locally, so anyone without those credentials can get it.

I see you're trying to solve this by disabling cache, and it should work now, but I'm not sure it'll work forever. We might get in-memory cache or something like that later.

Also, it works fine with basic authentication, but it won't work in npm 2 with bearer tokens, because token for one server doesn't make sense to use with another.

Can your issue be solved with advanced auth systems like LDAP for example?

Can your issue be solved with scoped packages in npm 2? We don't support them yet, but I can force the issue.

[samcday]

@rlidwka you're right, this PR is probably pretty dangerous.

Not long after I submitted this PR I looked more closely into the scopes stuff in npm@v2.0rc. It radically influenced my design. I've since rolled out a private endpoint that handles an internal package scope.

I'll close this PR.

I'm also interested what thoughts you had around what sinopia could/would do with scopes!

[rlidwka]

I'm also interested what thoughts you had around what sinopia could/would do with scopes!

#104

It'd be the same as all the other packages probably. Will need to change validation regexps.