warn if recommended env vars are missing

[Rich-Harris]

#7042. When using adapter-node, if the ORIGIN header is missing, and PROTOCOL_HEADER and HOST_HEADER aren't both set, then request URLs are very likely to be incorrect. That will result in the CSRF check misfiring, for example.

I don't 100% know if this solution is appropriate but it's the best I've got

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: /~https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[Conduitry]

Hm. In the absence of all of these, the adapter assumes that the origin is https:// followed by whatever the Host header container. Do we feel like that's often not going to be good enough? I don't know that we want to be making people worry about setting these when (presumably) that's the case they're most likely to be in in production.

At work, I have a multitenant app (with an external API) and there I can't set an fixed explicit ORIGIN env var, and so this sort of a warning message would encourage me to either (a) ignore it, or (b) jump through some hoops to find out what HTTP header might already be present and happen to equal https so that I can ultimately achieve the exact same result.

In this application, the only time I need to set ORIGIN is when running e2e tests, because they don't have an HTTPS proxy sitting in front of them then.

I would tend towards "document this more explicitly", but I don't know where to do that other than in /~https://github.com/sveltejs/kit/tree/master/packages/adapter-node#origin-protocol_header-and-host_header which I know a lot of people aren't going to look at.

[Rich-Harris]

The other thought I had was to document it at the point of need, i.e. when the cross-site-but-not-really POST fails. But it only actually affects adapter-node users. I agree with all your points though

[benmccann]

I don't quite understand why this would happen. It doesn't seem like it should be necessary to me because doesn't it just use the host header by default?

kit/packages/adapter-node/src/handler.js

Line 19 in 172e792

const host_header = env('HOST_HEADER', 'host').toLowerCase();

I guess you could also do it inside adapter-node's get_origin function (probably just once for the app) so that it only logs it if you actually do something using the origin. I'm not sure if SvelteKit will always call that internally though making that equivalent to always doing it

[Conduitry]

It does use the Host header by default, and it assumes HTTPS, which I think are good defaults. The question is whether we'd rather push people away from just using these defaults to try to avoid them getting bitten. I'd argue no. I think this warning would cause more chaos in the world than it removes. If we spruce up the Node adapter readme a tiny, we will at least have something to point to to tell people that this is the default and that's why their [whatever] is breaking in production.

[benmccann]

I'd agree this seems like it'd cause more trouble than it'd save. I think updating the readme to describe when you need to override the default would be better

[Rich-Harris]

closing in favour of #7744