fix(sveltekit): use env/static/private for env vars

[dievardump]

SvelteKit does not build with the latest version.

Two reasons:

• during build, sveltekit can only access "static" private env var, not dynamic
• during build, setEnvDefaults was not setting config.basePath which is read in the handle function, throwing an error for reading undefined.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
auth-docs	❌ Failed (Inspect)			Mar 1, 2024 5:03pm

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
next-auth-docs	⬜️ Ignored (Inspect)	Visit Preview		Mar 1, 2024 5:03pm

[vercel]

@dievardump is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

[ndom91]

Hmm so my local project using @auth/sveltekit@0.13.0 does build. Are you saying it builds but then you had errors running the built output?

[dievardump]

I am using @sveltejs/kit 2.5.1 and @sveltejs/adapter-node 4.0.1

When building I get the error:

Error: Cannot read values from $env/dynamic/private while prerendering (attempted to read env.AUTH_URL). Use $env/static/private instead
at Object.get (file:///home/dievardump/www/abc/apps/test-app/.svelte-kit/output/server/index.js:3397:11)
at createActionURL (file:///home/dievardump/www/abc/apps/test-app/.svelte-kit/output/server/chunks/hooks.server.js:126:25)
at auth (file:///home/dievardump/www/abc/apps/test-app/.svelte-kit/output/server/chunks/hooks.server.js:107:22

And when I change the dynamic lines for static, it is followed with an error with reading .length on an undefined (config.basePath) variable

So yes my bad, it's not while building but while pre-rendering some of the page.

[ndom91]

Yeah so the way that Svelte works, the AUTH_URL env var must be set (coming from dynamic env vars) otherwise it'll throw that first error you mentioned, right.

I'm not super experienced with Svelte though, is using the env vars here out of static a better way to go about this?

[dievardump]

For me, if you expect the variables to be set at build time, then you go for static. If you expect those variable can change during the life of the app, or they should only be set at runtime, then go for dynamic.

Because of the nature of the current module, accessed mostly as the first thing seen in the server through hook, and because you would expect the AUTH vars to be known and set at build time, I would suggest to use static over dynamic
Especially since dynamic vars can not be accessed during pre-rendering which is something that is used a lot by svelte-kit projects and would disallow to use this module in those projects

the doc says:

dynamic

This module provides access to runtime environment variables, as defined by the platform you're running on. For example if you're using adapter-node (or running vite preview), this is equivalent to process.env.

Dynamic environment variables cannot be used during prerendering.

static

Environment variables loaded by Vite from .env files and process.env.

Unlike $env/dynamic/private, the values exported from this module are statically injected into your bundle at build time, enabling optimisations like dead code elimination.

[ndom91]

@dievardump okay yeah that makes sense. I've updated from main, which included a bunch of updates regarding the sveltekit dev app. Do me a favor and take another look, see if it all still works as expected.

If yes, then I think we can go ahead with this!

[ThangHuuVu]

@dievardump great attempt, but I don't think this is a good idea. This comment puts it nicely: #9436 (comment)

Let us think a better approach to this issue. Is this related? #9809

[dievardump]

I think #9809 is specifically corrected by my changes to packages/frameworks-sveltekit/src/lib/env.ts
For some reasons some variables are not set during build time (not sure why).

I hadn't seen that issue before doing my PR. Building failed, I went into node_modules, I fixed, then I made a PR. But both errors mentioned in that issue should be fixed by my PR yes.

About the security of having the vars in the files: I can imagine why a security audit would flag it, but I would consider anyone having access to the "build image" as a trusted party. Because if they have access to the result of the build, they have access to the running environment, and therefore to the process.env vars. So using dynamic or static here wouldn't make much difference in term of security. If you can scan the files, you can do an "echo $AUTH_SECRET"

But if this is a problem, then I would use process.env.* instead of $env/*/private, to ensure it works in both pre-rendering and runtime

[ndom91]

@dievardump after some internal discussion, we've decided to stick with the dynamic env vars for the following reasons:

1. In many projects / companies, the application is often built once and then redeployed across various environments (preview, staging, prod, etc.) which implies requiring dynamic env vars like auth credentials and database urls.
2. In addition, sometimes auth credentials need to be rotated quickly without rebuilding and redeploying an entire application, which also implies requiring dynamic env vars

That being said, I appreciate the effort here and would still like to avoid the issue yuo've raised here about prerendering faililng if one of the env var's we've used in the library aren't defined by the user. As a concrete example, AUTH_URL is used in the library, but is an optional env var as we autodetect it in many environments. What do you think?

I'd also like to keep your change moving the if (building).. clause a bit lower

[dievardump]

The problem is still that it will not be possible to pre-render any route if using SvelteAuth and adapter-node if you keep using $env/dynamic/private, because it's not possible to access it at build time.

Would you then consider using process.env, which is what you do in the other adapters, which would allow for everything to work smoothly?

ps: using process.env will also allow projects that are using a prefix config.kit.env.privatePrefix for their private vars to use SvelteAuth. Because you are expecting specific var names, that will not be available in $env/dynamic/private if the project is using that privatePrefix feature

[WhyAsh5114]

Would really like a solution to this, prerender is really important for quick page loads and even setting one page to

export const prerender = true;

breaks the build process. Is there a temporary fix like adding AUTH_URL to the .env file? If yes, what should its value be by default?

[dievardump]

What you can do today to fix that is to only add SvelteKitAuth.handle to the sequence if build == false

But the better solution for the future would be for the plugin to use process.env instead of $env/*/private

[ndom91]

Hey chiming in with an update, so we definitely don't want to go with the env/static/private option to bake the variables into the build output for the reasons listed above.

We took another look at this and talked to some other svelte folks and it looks like basically during prerendering you shuoldn'tn rely on any authenticated info to begin with. Therefore, we're tryign to find a way to skip calling the auth routes during build. Like if (building) skip.

But the problem is, those routes are all dynamic from the hooks.server.ts handle fn. So as soonas you have a <a href="/auth/signin" .. in one of your pages, it'll try to hit that route during prerender and it'll get a 404 since that route doesn't have a page or page.server file, right.

Anyway, long story short. I don't think we want to merge any of these changes unfortunately. I've opened a new PR attempting to solve the prerender issue and we'd still love yuor help there if yuo're interested 🙏

#10339

[p-arndt]

Its still failing :(