dbAuth: No more process.env.RWJS_API_DBAUTH_URL

[Tobbe]

Using process.env is troublesome for Vite.

Also, overriding default values by passing them as config to the auth client brings dbAuth more inline with the other auth providers.

This PR also adds tests for webAuthn, that we were lacking. And fixes a bug where the cookie matching was too lax.

[jtoar]

Could you expand on Vite not liking env vars? env vars seem very necessary for auth to me, and nearly all the other auth providers use them during initialization

[dac09]

Could you expand on Vite not liking env vars? env vars seem very necessary for auth to me, and nearly all the other auth providers use them during initialization

We should avoid using process.env in the framework code (not in the user's project) - because Vite prefers using import.meta.env. I can make it work with process.env, but we'll be compounding problems later - I can't exactly remember why, but I made a note in my experiments to avoid using process.env where possible! 🤷

All the auth providers, on the web side instantiate a client with envars in the user's codebase, then pass it to the framework - process.env is never used in the provider or framework code (on the web side). But in dbAuth we directly configure it from values in the Redwood.toml - this is inconsistent, and also the cause of incompatibility between webpack and vite.

[dac09]

@Tobbe changes look good to me... but just wondering where we pass in the CORS config for dbAuth? It might make sense that its configured the same way. https://redwoodjs.com/docs/cors#graphql-xhr-credentials

[dac09]

We should avoid using process.env in the framework code (not in the user's project) - because Vite prefers using import.meta.env. I can make it work with process.env, but we'll be compounding problems later - I can't exactly remember why, but I made a note in my experiments to avoid using process.env where possible! 🤷

Found a note on why:

// @mark instead of using process.env, we use RWJS_GLOBALS
// This is because it seems to interfere with the node polyfills in esbuildOptions, for SSR

[Tobbe]

Thanks @dac09. Dom and I talked yesterday and I explained the Vite env vars stuff. But good to also have it "on paper".

And about CORS, it's still configured the same way as it was before. You pass a config object to dbAuth when you set it up. I reused that same config object for the custom api url. Just added another option to it. So nothing has (or need to) change regarding CORS

[dac09]

Thanks @Tobbe! We should think about moving the CORs config too perhaps (not in this PR obviously) - because to me with the new auth "thing" we have in in src/web/auth it feels like the most obvious place to configure your client!

[redwoodjs-bot]

🔔 @jtoar, @Tobbe—I couldn't cherry pick this one. If you want it in the next release, you'll have to cherry pick it manually.