Thoughts on supporting authorization headers when fetching dependencies

[reggi]

I've been thinking about how to maintain private files on a server and allowing deno to pull in those files.

Are there any thoughts on supporting basic auth or allowing deno to send any kind of auth header token?

[reggi]

Here's also an idea:

import { env } from "deno";

const auth = env()["AUTH"]

import(`https://pkg.example.com/lodash@4.17.11/index.js?auth=${auth}`).then(m => {
    console.log(m)
})

[davidnorthetal]

@reggi I tried using something like your example but it wouldn't work, I don't think import works at runtime at all? - so we can't construct URLs at runtime

I take your idea was not intended as a working example

[davidnorthetal]

I wonder if like authentication (or mere string replacements) for URL imports ought to be supported by deno itself, or if deno expects users to build proxy-servers instead in order to achieve this.

It seems to me the former is preferred, enabling a way (like a .denorc or via ENV vars or whatever) to configure deno in a way so that it can deal with various http authentication schemes?

[davidnorthetal]

this might relate to #1921 which might enable people to authenticate with tokens passed as URL params?

[ry]

Auth can be done using the --cert flag now which was added in 2e7d449. Although that doesn't add auth headers, I think in principle it solves this issue. Please open a new issue if the actual AUTH header (or others) is needed.

[brandonkal]

As far as I can tell, --cert adds an untrusted RootCA but doesn't help with presenting a client certificate to the private server for mTLS.